WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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