Re: [Qemu-devel] Linux kernel polling for QEMU

[Stefan Hajnoczi]

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

signature.asc
Description: PGP signature