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 <a...@redhat.com> 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
