On Wed, Nov 30, 2016 at 07:41:11PM +0200, Avi Kivity wrote: > 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.
You are trying to improve on the latency of non-blocking ppoll(2)/epoll_wait(2) call? Stefan
Description: PGP signature