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

[Avi Kivity <avi@qumranet.com>]

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