This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signal

Anthony Liguori writes ("[Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle 
terminating signals."):
> The race I know of is that you may get an aio signal completion before 
> select but after you've already qemu_aio_poll()'d.  In practice, we only 
> sleep for 10ms at a time in select() so the race is handled by that.  If 
> we wanted to increase the amount of time we slept, we would have to 
> handle this race.

Yes.  And, 10ms is too long anyway for reasonable performance.  During
my merge with upstream I found that the qemu aio functionality (which
was done quite differently to the old xen ioemu) caused a severe
performance regression under some conditions because of this race.

> In KVM, we sleep for 1s in select() and use signalfd() to receive the 
> aio notifications.  For older hosts, we emulate signalfd using a thread 
> and the pipe-to-self trick.

Why does it need a thread ?  You can just write to the pipe in the
signal handler.  I'll post my code.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>