Should I resubmit the patch? Thanks, -peter
On Mar 27, 2012, at 8:34 AM, Avi Kivity <a...@redhat.com> 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 <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 >