On 11/29/2016 12:45 PM, Stefan Hajnoczi wrote:
On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote:
On 28/11/2016 16:29, Stefan Hajnoczi wrote:
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
This would add a system call every time the main loop processes a vring,
wouldn't it?
Yes, this is a problem and is the reason I haven't finished implementing
a test using QEMU yet.
My proposed eventfd polling mechanism doesn't work well with descriptor
ring indices because the polling info needs to be updated each event
loop iteration with the last seen ring index.
This can be solved by making struct eventfd_poll_info.value take a
userspace memory address. The value to compare against is fetched each
polling iteration, avoiding the need for ioctl calls.
Maybe we could do the same for sockets? When data is available on a socket
(or when it becomes writable), write to a user memory location.
I, too, have an interest in polling; in my situation most of the polling
happens in userspace.