Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
On 8/20/07, malc <[EMAIL PROTECTED]> wrote:
> On Mon, 20 Aug 2007, Luca Tettamanti wrote:
>
> > Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto:
> >> Luca wrote:
> >>> On 8/19/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> >>>
> +static uint64_t qemu_next_deadline(void) {
> +uint64_t nearest_delta_us = ULLONG_MAX;
> +uint64_t vmdelta_us;
>
> >>>
> >>> Hum, I introduced a bug here... those vars should be signed.
> >>>
> >>> On the overhead introduced: how do you measure it?
> >>>
> >>>
> >>
> >> Run a 100Hz guest, measure cpu usage using something accurate like
> >> cyclesoak, with and without dynticks, with and without kvm.
> >
> > Ok, here I've measured the CPU usage on the host when running an idle
> > guest.
> >
[...]
> The upshot is this - if you have used any standard utility (iostat,
> top - basically anything /proc/stat based) the accounting has a fair
> chance of being inaccurate. If cyclesoak is what you have used then
> the results should be better, but still i would be worried about
> them.
Yes, I've used cyclesoak.
Luca
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
Avi Kivity wrote: Paul Brook wrote: Yes, good thinking, but this should only be done if it actually impacts something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it introduces extra complexity. If the overhead is that small, why are we touching this code in the first place? Accuracy is much more important from my point of view. Also, the reduction in the number of signals delivered when the guest uses 100Hz is significant. You'd also get better battery life on laptops. -- error compiling committee.c: too many arguments to function
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
Jamie Lokier wrote: > Paul Brook wrote: > >>> Yes, good thinking, but this should only be done if it actually impacts >>> something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it >>> introduces extra complexity. >>> >> If the overhead is that small, why are we touching this code in the first >> place? >> > > Insightful. > > A benchmark result was posted which is rather interesting: > > >> [EMAIL PROTECTED] ~]$ time ./hackbench 50 >> x86_64 host : real 0m10.845s >> x86_64 host, bound to 1 cpu : real 0m21.884s >> i386 guest+unix clock : real 0m49.206s >> i386 guest+hpet clock : real 0m48.292s >> i386 guest+dynticks clock : real 0m28.835s >> >> Results are repeatable and verfied with a stopwatch because I didn't >> believe them at first :) >> > > I am surprised if 1000 redundant SIGALRMs per second is really causing > 70% overhead in normal qemu execution, except on a rather old or slow > machine where signal delivery is very slow. > No, something else is happening here. On kvm, a signal is maybe 10us, to the SIGALRMs represent 1% of overhead. Respectable, but not more. I suspect that the increased accuracy causes something to behave better (or just differently). This won't be representative. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
Paul Brook wrote: > > Yes, good thinking, but this should only be done if it actually impacts > > something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it > > introduces extra complexity. > > If the overhead is that small, why are we touching this code in the first > place? Insightful. A benchmark result was posted which is rather interesting: >[EMAIL PROTECTED] ~]$ time ./hackbench 50 >x86_64 host : real 0m10.845s >x86_64 host, bound to 1 cpu : real 0m21.884s >i386 guest+unix clock : real 0m49.206s >i386 guest+hpet clock : real 0m48.292s >i386 guest+dynticks clock : real 0m28.835s > >Results are repeatable and verfied with a stopwatch because I didn't >believe them at first :) I am surprised if 1000 redundant SIGALRMs per second is really causing 70% overhead in normal qemu execution, except on a rather old or slow machine where signal delivery is very slow. It would be good to understand the cause of that benchmark result. -- Jamie
RE: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
>>> Yes, good thinking, but this should only be done if it actually >impacts >>> something. Reducing overhead from 0.1% to 0.05% is not worthwhile if >it >>> introduces extra complexity. >>> >> >> >> If the overhead is that small, why are we touching this code in the >first >> place? >> > >Accuracy is much more important from my point of view. Also, the >reduction in the number of signals delivered when the guest uses 100Hz >is significant. > Actually the main motivation for dyn-tick in qemu was to enable smooth fix of time drift problem in the guests. On kernels without dyn-tick enabled sigalarm didn't reach qemu on accurate times, thus caused convergence of several pit irqs into one. Currently we use a time-drift-fix written by Uri Lublin which counts the number of irq acked by the guest and tries to inject another one immidietly until the drift is fixed. This worked fine but caused jumps for multimedia applications. We wanted a way to smooth it by increasing the rate of pit timer in case of drift to a frequency higher than 1000HZ until the drift is fixed. Dan K. tries to test application behviour with it. -- Dor.
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
Paul Brook wrote: Yes, good thinking, but this should only be done if it actually impacts something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it introduces extra complexity. If the overhead is that small, why are we touching this code in the first place? Accuracy is much more important from my point of view. Also, the reduction in the number of signals delivered when the guest uses 100Hz is significant. -- error compiling committee.c: too many arguments to function
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
> Yes, good thinking, but this should only be done if it actually impacts > something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it > introduces extra complexity. If the overhead is that small, why are we touching this code in the first place? Paul
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2
Jamie Lokier wrote: Avi Kivity wrote: In this case the dyn-tick minimum res will be 1msec. I believe it should work ok since this is the case without any dyn-tick. Actually minimum resolution depends on host HZ setting, but - yes - essentially you have the same behaviour of the "unix" timer, plus the overhead of reprogramming the timer. Is this significant? At a high guest HZ, this is could be quite a lot of additional syscalls right? At HZ=1000, this adds a small multiple of 1000 syscalls, which is a fairly small overhead. Small, but maybe measurable. That overhead could be removed if the dyn-tick code were to predictively set the host timer into a repeating mode when guests do actually require a regular tick. I'm thinking when it detects it needed a tick a small number of times in a row, with the same interval, it could set the host timer to trigger repeatedly at that interval. Then it wouldn't need to reprogram if that stayed the same (except maybe to correct for drift?) If a tick then _wasn't_ required for that interval (i.e. it was required for less, more, or not at all), then it would have to reprogram the host timer. If it really mattered, it wouldn't have to reprogram the host timer when the next required tick is further in the future or not at all; it would simply be a redundant SIGALRM. In weird cases that's worthwhile, but I suspect it generally isn't. Yes, good thinking, but this should only be done if it actually impacts something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it introduces extra complexity. -- error compiling committee.c: too many arguments to function
