login
Search
Avi Kivity suggested that combining KVM, the Kernel-based Virtual Machine [story], with the dyntick patch [story] could improve overall KVM performance. He noted that it would likely improve performance of both the host by "avoiding expensive vmexits due to useless timer interrupts," as well as on the guest by "reducing the load on the host when the guest is idling (currently an idle guest consumes a few percent cpu)". Ingo Molnar [interview] pointed out that KVM with his -rt kernel already works with dynticks enabled on both the host and the guest, "using the dynticks code from the -rt kernel makes the overhead of an idle guest go down by a factor of 10-15". Ingo added that he hopes the dyntick patch will be ready to be merged into the upcoming mainline 2.6.21 kernel.
Rik van Riel [interview] noted that there were other ways to reduce the load of the guest when it's idling, "you do not need dynticks for this actually. Simple no-tick-on-idle like Xen has works well enough." Ingo explained, "s390 (and more recently Xen too) uses a next_timer_interrupt() based method to stop the guest tick - which works in terms of reducing guest load, but it doesnt stop the host-side interrupt. The highest quality approach is to have dynticks on both the host and the guest, and this also gives high-resolution timers and a modernized time/timer-events subsystem for both the host and the guest."
From: Avi Kivity [email blocked] To: Ingo Molnar [email blocked] Subject: kvm & dyntick Date: Thu, 11 Jan 2007 18:08:38 +0200 It occurs to me that kvm could benefit greatly from dyntick: dyntick-enabled host: - generate virtual interrupts at whatever HZ the guest programs its timers, be it 100, 250, 1000 or whatever - avoid expensive vmexits due to useless timer interrupts dyntick-enabled guest: - reduce the load on the host when the guest is idling (currently an idle guest consumes a few percent cpu) What are the current plans wrt dyntick? Is it planned for 2.6.21? -- error compiling committee.c: too many arguments to function
From: Rik van Riel [email blocked] Subject: Re: kvm & dyntick Date: Fri, 12 Jan 2007 00:34:34 -0500 Avi Kivity wrote: > dyntick-enabled guest: > - reduce the load on the host when the guest is idling > (currently an idle guest consumes a few percent cpu) You do not need dynticks for this actually. Simple no-tick-on-idle like Xen has works well enough. While you're modifying the timer code, you might also want to add proper accounting for steal time. Time during which your guest had a runnable process, but was not actually running itself, should not be accounted against the currently running process. I wonder if it would be possible to simply copy some of the timer code from Xen. They have the timing quirks worked out very well and their timer_interrupt() is pretty nice code. (Now I need to buy myself another VT box so I can help out with KVM :)) http://virt.kernelnewbies.org/ParavirtBenefits has some other features you may want to have :))) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic.
From: Ingo Molnar [email blocked] Subject: Re: kvm & dyntick Date: Fri, 12 Jan 2007 07:20:07 +0100 * Avi Kivity [email blocked] wrote: > It occurs to me that kvm could benefit greatly from dyntick: > > dyntick-enabled host: > - generate virtual interrupts at whatever HZ the guest programs its > timers, be it 100, 250, 1000 or whatever > - avoid expensive vmexits due to useless timer interrupts > > dyntick-enabled guest: > - reduce the load on the host when the guest is idling > (currently an idle guest consumes a few percent cpu) yeah. KVM under -rt already works with dynticks enabled on both the host and the guest. (but it's more optimal to use a dedicated hypercall to set the next guest-interrupt) > What are the current plans wrt dyntick? Is it planned for 2.6.21? yeah, we hope to have it in v2.6.21. note that s390 (and more recently Xen too) uses a next_timer_interrupt() based method to stop the guest tick - which works in terms of reducing guest load, but it doesnt stop the host-side interrupt. The highest quality approach is to have dynticks on both the host and the guest, and this also gives high-resolution timers and a modernized time/timer-events subsystem for both the host and the guest. Ingo
From: Ingo Molnar [email blocked] Subject: Re: kvm & dyntick Date: Fri, 12 Jan 2007 11:19:31 +0100 * Ingo Molnar [email blocked] wrote: > > dyntick-enabled guest: > > - reduce the load on the host when the guest is idling > > (currently an idle guest consumes a few percent cpu) > > yeah. KVM under -rt already works with dynticks enabled on both the > host and the guest. (but it's more optimal to use a dedicated > hypercall to set the next guest-interrupt) using the dynticks code from the -rt kernel makes the overhead of an idle guest go down by a factor of 10-15: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2556 mingo 15 0 598m 159m 157m R 1.5 8.0 0:26.20 qemu ( for this to work on my system i have added a 'hyper' clocksource hypercall API for KVM guests to use - this is needed instead of the running-to-slowly TSC. ) Ingo
From: Avi Kivity [email blocked] Subject: Re: kvm & dyntick Date: Fri, 12 Jan 2007 19:04:31 +0200 Ingo Molnar wrote: > * Ingo Molnar [email blocked] wrote: > > >>> dyntick-enabled guest: >>> - reduce the load on the host when the guest is idling >>> (currently an idle guest consumes a few percent cpu) >>> >> yeah. KVM under -rt already works with dynticks enabled on both the >> host and the guest. (but it's more optimal to use a dedicated >> hypercall to set the next guest-interrupt) >> > > using the dynticks code from the -rt kernel makes the overhead of an > idle guest go down by a factor of 10-15: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 2556 mingo 15 0 598m 159m 157m R 1.5 8.0 0:26.20 qemu > > As usual, great news. > ( for this to work on my system i have added a 'hyper' clocksource > hypercall API for KVM guests to use - this is needed instead of the > running-to-slowly TSC. ) > What's the problem with the TSC? The only issue I'm aware of is that the tsc might go backwards if the vcpu is migrated to another host cpu (easily fixed). A pv clocksource makes sense in any case. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
