[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastr

From: Avi Kivity
Subject: Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
Date: Sun, 19 Aug 2007 16:48:06 +0300
User-agent: Thunderbird (X11/20070419)

Jamie Lokier wrote:
Avi Kivity wrote:
In this case the dyn-tick minimum res will be 1msec. I believe it should
work ok since this is the case without any dyn-tick.
Actually minimum resolution depends on host HZ setting, but - yes -
essentially you have the same behaviour of the "unix" timer, plus the
overhead of reprogramming the timer.
Is this significant?  At a high guest HZ, this is could be quite a lot
of additional syscalls right?

At HZ=1000, this adds a small multiple of 1000 syscalls, which is a fairly small overhead.

Small, but maybe measurable.

That overhead could be removed if the dyn-tick code were to
predictively set the host timer into a repeating mode when guests do
actually require a regular tick.

I'm thinking when it detects it needed a tick a small number of times
in a row, with the same interval, it could set the host timer to
trigger repeatedly at that interval.  Then it wouldn't need to reprogram
if that stayed the same (except maybe to correct for drift?)

If a tick then _wasn't_ required for that interval (i.e. it was
required for less, more, or not at all), then it would have to
reprogram the host timer.  If it really mattered, it wouldn't have to
reprogram the host timer when the next required tick is further in the
future or not at all; it would simply be a redundant SIGALRM.  In
weird cases that's worthwhile, but I suspect it generally isn't.

Yes, good thinking, but this should only be done if it actually impacts something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it introduces extra complexity.

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]