On 12/01/2016 01:45 PM, Stefan Hajnoczi wrote:
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:
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?

Yes, but the concern is for throughput, not latency.

My main loop looks like

   execute some tasks
   poll from many sources

Since epoll_wait(..., 0) has non-trivial costs, I have to limit the polling rate, and even so it shows up in the profile. If the cost were lower, I could poll at a higher frequency, resulting in lower worst-case latencies for high-priority tasks.

Reply via email to