|
[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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |