On Wed, May 23, 2012 at 2:31 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 22.05.2012 14:03, ronnie sahlberg wrote:
[]
Doh, now I remember. Whenever you change the aio handlers you need to
call qemu_notify_event() afterwards, if the handler may fire right away.
Thanks. I just confirmed
Hi Stefan
On Mon, May 21, 2012 at 11:20 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Mon, May 21, 2012 at 12:00 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
Yes, I use IDE since I boot from this LUN.
I just managed to track it down to the IDE changes.
It looks like basically
Hi,
Now that I see what happens, I can easily workaround this in block/iscsi.c
by the patch below, but I dont know if this is the right thing to do.
It does appear that here, when I use qemu_set_fd_handler() and add a
handler for writeble it takes 55ms before the event system notices
this and
Il 22/05/2012 11:15, ronnie sahlberg ha scritto:
Hi,
Now that I see what happens, I can easily workaround this in block/iscsi.c
by the patch below, but I dont know if this is the right thing to do.
It does appear that here, when I use qemu_set_fd_handler() and add a
handler for writeble
On Tue, May 22, 2012 at 7:29 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 22/05/2012 11:15, ronnie sahlberg ha scritto:
Hi,
Now that I see what happens, I can easily workaround this in block/iscsi.c
by the patch below, but I dont know if this is the right thing to do.
It does appear that
None of the other drivers in block/*.c call qemu_notify_event()
Do you you think those should be audited and have this call added to
where required ?
regards
ronnie sahlberg
On Tue, May 22, 2012 at 7:48 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
On Tue, May 22, 2012 at 7:29 PM, Paolo
On 22.05.2012 14:03, ronnie sahlberg wrote:
[]
Doh, now I remember. Whenever you change the aio handlers you need to
call qemu_notify_event() afterwards, if the handler may fire right away.
Thanks. I just confirmed that qemu_notify_event() fixes the issue.
Ill send a patch that uses
List, Kevin,
Since this merge :
commit 1f8bcac09af61e58c5121aa0a932190700ad554d
Merge: cb4c254 1042ec9
Author: Anthony Liguori aligu...@us.ibm.com
Date: Mon Apr 23 14:27:04 2012 -0500
Merge remote-tracking branch 'kwolf/for-anthony' into staging
* kwolf/for-anthony: (38 commits)
Am 21.05.2012 08:07, schrieb ronnie sahlberg:
List, Kevin,
Since this merge :
commit 1f8bcac09af61e58c5121aa0a932190700ad554d
Merge: cb4c254 1042ec9
Author: Anthony Liguori aligu...@us.ibm.com
Date: Mon Apr 23 14:27:04 2012 -0500
Merge remote-tracking branch 'kwolf/for-anthony'
Il 21/05/2012 12:45, Kevin Wolf ha scritto:
I have not yet found the exact part of this big patch that cause this
slowdown, but will continue investigating.
I am posting this here in case someone has any idea or if 55ms rings any
bells.
55ms is the frequency of the PIT while the BIOS is
Yes, I use IDE since I boot from this LUN.
I just managed to track it down to the IDE changes.
It looks like basically this change triggered it :
commit bef0fd5958120542f126f2dedbfce65d8839a94d
Author: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Date: Thu Mar 29 10:31:30 2012 +0100
ide:
On Mon, May 21, 2012 at 12:00 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
Yes, I use IDE since I boot from this LUN.
I just managed to track it down to the IDE changes.
It looks like basically this change triggered it :
commit bef0fd5958120542f126f2dedbfce65d8839a94d
Author:
12 matches
Mail list logo