Re: [Qemu-devel] [PATCH] Small change to remove short 250us timeouts every other time through the wait loop.

[Peter Portante]

Should I resubmit the patch? Thanks,

-peter

On Mar 27, 2012, at 8:34 AM, Avi Kivity <address@hidden> wrote:

> On 03/22/2012 04:59 PM, Peter Portante wrote:
>> Basically, the main wait loop calls qemu_run_all_timers() unconditionally. 
>> The
>> first thing this routine used to do is to see if a timer had been serviced,
>> and then reset the loop timeout to the next deadline.
>> 
>> However, the new deadlines had not been calculated at that point, as
>> qemu_run_timers() had not been called yet for each of the clocks. So
>> qemu_rearm_alarm_timer() would end up with a negative or zero deadline, and
>> default to setting a 250us timeout for the loop.
>> 
>> As qemu_run_timers() is called for each clock, the real deadlines would be 
>> put
>> in place, but because a loop timeout was already set, the loop timeout would
>> not be changed.
>> 
>> Once that 250us timeout fired, the real deadline would be used for the
>> subsequent timeout.
>> 
>> For idle VMs, this effectively doubles the number of times through the loop,
>> doubling the number of select() system calls, timer calls, etc. putting added
>> scheduling pressure on the kernel. And under cgroups, this really causes a 
>> big
>> problem because the cgroup code does not scale well.
>> 
>> By simply running the timers before trying to rearm the timer, we always 
>> rearm
>> with a non-zero deadline, effectively halving the number of system calls.
> 
> Reviewed-by: Avi Kivity <address@hidden>
> 
> Note the canonical subject line for patches is "subsystem: short
> description", in this case something like "qemu-timer: remove spurious
> host alarm wakeups" would be a good fit.
> 
> -- 
> error compiling committee.c: too many arguments to function
>