Re: [kvm-devel] kvm & dyntick
* Dor Laor <[EMAIL PROTECTED]> wrote:
> Afterwards we'll need to compensate the lost alarm signals to the
> guests by using one of
> - hrtimers to inject the lost interrupts for specific guests. The
> problem this will increase the overall load.
> - Injecting several virtual irq to the guests one after another
> (using interrupt window exit). The question is how the guest will be
> effected from this unfair behavior.
well, the most important thing would be to fix qemu to:
- not use a 1024 /dev/rtc stream of signals as its clock emulation
source
i hacked that out of qemu, only to find out that qemu then uses periodic
itimers. Instead of that it should use one-shot itimers, driven by the
expiry time of the next clock. I.e. this code in vl.c, in
host_alarm_handler():
if (qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
qemu_get_clock(vm_clock)) ||
qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock))) {
should start an itimer with an expiry time of:
active_timers[QEMU_TIMER_VIRTUAL]->expire_time - qemu_get_clock(vm_clock)
or:
active_timers[QEMU_TIMER_REALTIME]->expire_time - qemu_get_clock(rt_clock)
whichever is smaller. Furthermore, whenever timer->expire_time is
changed in qemu_mod_timer(), this set-the-next-itimer-expiry-time code
needs to be called. Would anyone like to try that?
this will reduce the host Qemu wakeup rate from 1000-1100/sec to the
guest's 4-5/sec wakeup rate - resulting in 0.01% CPU overhead from a
single idle guest. Current unmodified Qemu causes 10-20% CPU overhead
from a single idle guest.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] kvm dyntick
* Dor Laor [EMAIL PROTECTED] wrote:
Afterwards we'll need to compensate the lost alarm signals to the
guests by using one of
- hrtimers to inject the lost interrupts for specific guests. The
problem this will increase the overall load.
- Injecting several virtual irq to the guests one after another
(using interrupt window exit). The question is how the guest will be
effected from this unfair behavior.
well, the most important thing would be to fix qemu to:
- not use a 1024 /dev/rtc stream of signals as its clock emulation
source
i hacked that out of qemu, only to find out that qemu then uses periodic
itimers. Instead of that it should use one-shot itimers, driven by the
expiry time of the next clock. I.e. this code in vl.c, in
host_alarm_handler():
if (qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
qemu_get_clock(vm_clock)) ||
qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock))) {
should start an itimer with an expiry time of:
active_timers[QEMU_TIMER_VIRTUAL]-expire_time - qemu_get_clock(vm_clock)
or:
active_timers[QEMU_TIMER_REALTIME]-expire_time - qemu_get_clock(rt_clock)
whichever is smaller. Furthermore, whenever timer-expire_time is
changed in qemu_mod_timer(), this set-the-next-itimer-expiry-time code
needs to be called. Would anyone like to try that?
this will reduce the host Qemu wakeup rate from 1000-1100/sec to the
guest's 4-5/sec wakeup rate - resulting in 0.01% CPU overhead from a
single idle guest. Current unmodified Qemu causes 10-20% CPU overhead
from a single idle guest.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] kvm & dyntick
On Fri, 2007-01-12 at 15:25 -0800, Dor Laor wrote: > This is great news for PV guests. > > Never-the-less we still need to improve our full virtualized guest > support. Full virtualized guests, which have their own dyntick support, are fine as long as we provide local apic emulation for them. If a guest does not have that, it will use the periodic mode. There is no way to circumvent this. We do not know, whether the guest relies on that periodic interrupt or not. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [kvm-devel] kvm & dyntick
>* Ingo Molnar <[EMAIL PROTECTED]> 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 %MEMTIME+ 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 This is great news for PV guests. Never-the-less we still need to improve our full virtualized guest support. First we need a mechanism (can we use the timeout_granularity?) to dynamically change the host timer frequency so we can support guests with 100hz that dynamically change their freq to 1000hz and back. Afterwards we'll need to compensate the lost alarm signals to the guests by using one of - hrtimers to inject the lost interrupts for specific guests. The problem this will increase the overall load. - Injecting several virtual irq to the guests one after another (using interrupt window exit). The question is how the guest will be effected from this unfair behavior. Can dyntick help HVMs? Will the answer be the same for guest-dense hosts? I understood that the main gain of dyn-tick is for idle time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [kvm-devel] kvm dyntick
* Ingo Molnar [EMAIL PROTECTED] 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 %MEMTIME+ 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 This is great news for PV guests. Never-the-less we still need to improve our full virtualized guest support. First we need a mechanism (can we use the timeout_granularity?) to dynamically change the host timer frequency so we can support guests with 100hz that dynamically change their freq to 1000hz and back. Afterwards we'll need to compensate the lost alarm signals to the guests by using one of - hrtimers to inject the lost interrupts for specific guests. The problem this will increase the overall load. - Injecting several virtual irq to the guests one after another (using interrupt window exit). The question is how the guest will be effected from this unfair behavior. Can dyntick help HVMs? Will the answer be the same for guest-dense hosts? I understood that the main gain of dyn-tick is for idle time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] kvm dyntick
On Fri, 2007-01-12 at 15:25 -0800, Dor Laor wrote: This is great news for PV guests. Never-the-less we still need to improve our full virtualized guest support. Full virtualized guests, which have their own dyntick support, are fine as long as we provide local apic emulation for them. If a guest does not have that, it will use the periodic mode. There is no way to circumvent this. We do not know, whether the guest relies on that periodic interrupt or not. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
