qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Linux kernel polling for QEMU
Date: Fri, 2 Dec 2016 10:12:35 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Thu, Dec 01, 2016 at 09:35:27AM -0500, Paolo Bonzini wrote:
> > > > 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.
> 
> IMHO, the ideal model wouldn't enter the kernel at all unless you _want_
> to go to sleep.

Something like mmapping an epoll file descriptor to get a ring of
epoll_events.  It has to play nice with blocking epoll_wait(2) and
ppoll(2) of an eventpoll file descriptor so that the userspace process
can go to sleep without a lot of work to switch epoll wait vs mmap
modes.

I'm bothered by the fact that the kernel will not be able to poll NIC or
storage controller rings if userspace is doing the polling :(.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]