[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.