On Mon, Nov 28, 2016 at 11:31:43AM +0200, Eliezer Tamir wrote: > + Eric, Willem > > On 24/11/2016 17:12, Stefan Hajnoczi wrote: > > I looked through the socket SO_BUSY_POLL and blk_mq poll support in > > recent Linux kernels with an eye towards integrating the ongoing QEMU > > polling work. The main missing feature is eventfd polling support which > > I describe below. > ... > > State of polling in Linux > > ------------------------- > > SO_BUSY_POLL causes recvmsg(2), select(2), and poll(2) family system > > calls to spin awaiting new receive packets. From what I can tell epoll > > is not supported so that system call will sleep without polling. > > At the time I sent out an RFC for epoll() SO_BUSY_POLL support. > https://lkml.org/lkml/2013/8/21/192 > > In hindsight I think the way I tracked sockets was over-complicated. > What I would do today would be to extend the API to allow the user > to tell epoll which socket/queue combinations are interesting. > > I would love to collaborate on this with you, though I must confess that > my resources at the moment are limited and the setup I used for testing > no longer exists.
Thanks for sharing the link. I'll let you know before embarking on an effort to make epoll support busy_loop. At the moment I'm still evaluating whether the good results we've gotten from polling in QEMU userspace are preserved when polling is shifted to the kernel. FWIW I've prototyped ioctl(EVENTFD_SET_POLL_INFO) but haven't had a chance to test it yet: https://github.com/stefanha/linux/commit/133e8f1da8eb5364cd5c5f7162decbc79175cd13 Stefan
signature.asc
Description: PGP signature