Re: [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

Avi Kivity
2007-08-19T13:48:06Z

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