[Qemu-devel] RE: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure -take2
I think this is a really nice and important patch set. Just a couple things: On Sun, 2007-08-19 at 00:02 +0200, Luca Tettamanti 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? I believe it's no significant since without dyn-tick the guest will get the same amount of signals so the overhead is doubling the syscalls (not a magnitude bigger). On the other size guests with low HZ and linux guests with dyn-tick will enojy from lesser syscalls.
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
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
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? 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.
[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
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?
Luca
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: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
In 8/16/07, malc [EMAIL PROTECTED] wrote: Very long time ago i changed the ISA DMA API to address some of the critique that Fabrice expressed, i can't remember offhand if that included removal of explicit position passing or not (the patch is on some off-line HDD so it's not easy to check whether it's in fact so) http://www.mail-archive.com/qemu-devel@nongnu.org/msg06594.html If needed i can try to locate the patch but the FDC problem still needs to be addressed by someone. That could be interesting, please try to find it. I guess the patch would be 7_aqemu?
Re: [Qemu-devel] sparc kqemu?
On 8/16/07, Jonathan Kalbfeld [EMAIL PROTECTED] wrote: Is this on the horizon? Is there any interest in it? For Sparc32 this could be possible, the page table structures are not unlike i386 ones. Given the death of Sparc32 distros I don't think there would be much interest. On Sparc64 there are no in-memory structures for MMU, instead page table entries are pushed into TLB when needed. I think kqemu would have to mess with the OS page structures or install its own TLB handler. As Sparc architecture is much better on virtualisation than x86, it should be possible to port kvm instead.
RE: [kvm-devel] [Qemu-devel] Re: [PATCH 0/4] Rework alarmtimer 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. while I don't know the benchmark [I head it's something like paralled chat messaging, the performance gain is probably achieved by improved latency and response times that the dyn-tick provides.
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.
[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
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.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
[Qemu-devel] Sparc guest
On the CVS version, networking has stopped working again with Sparc guests running Debian Linux. It had been working fine for a few weeks, but the latest version is broken again, with the device not being found. -Nigel
[Qemu-devel] qemu/darwin-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 21:43:54 Modified files: darwin-user: main.c Log message: Darwin-user: Compile fix for ppc targets, by Pierre d'Herbemont. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/main.c?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] qemu/hw ide.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 21:46:53 Modified files: hw : ide.c Log message: Fix bugs in the ATAPI cdrom driver, by Brandon Philips. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemur1=1.63r2=1.64
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 21:56:03 Modified files: . : vl.c vl.h Log message: Rework alarm timer infrastrucure, by Luca Tettamanti. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.323r2=1.324 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.260r2=1.261
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/08/19 22:09:40 Modified files: . : vl.c Log message: Add -clock option, by Luca Tettamanti. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.324r2=1.325
Re: [Qemu-devel] [PATCH][RFC] Fix bugs in the ATAPI cdrom driver
Brandon Philips wrote: On 17:42 Fri 17 Aug 2007, Matthew Kent wrote: On Fri, 2007-17-08 at 16:43 -0700, Brandon Philips wrote: The new libata-eh in the Linux kernel is throwing a fit over the QEMU cdrom device for two reasons: Nice thanks, was suffering from this issue as well. Tested with some linux 2.6.23-rc3 guests, looks great now. Great. I would like to see someone from the QEMU project sign off on the correctness of the code too before we carry the patch in our package. Committed. Thiemo
