qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Avi Kivity <avi@scylladb.com>,
	Willem de Bruijn <willemb@google.com>,
	Fam Zheng <famz@redhat.com>,
	Eliezer Tamir <eliezer.tamir@linux.intel.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Jens Axboe <axboe@fb.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Davide Libenzi <davidel@xmailserver.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] Linux kernel polling for QEMU
Date: Fri, 2 Dec 2016 10:12:35 +0000	[thread overview]
Message-ID: <20161202101235.GB14548@stefanha-x1.localdomain> (raw)
In-Reply-To: <1469768236.987810.1480602927225.JavaMail.zimbra@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2016-12-02 10:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-24 15:12 [Qemu-devel] Linux kernel polling for QEMU Stefan Hajnoczi
2016-11-28  9:31 ` Eliezer Tamir
2016-11-28 15:29   ` Stefan Hajnoczi
2016-11-28 15:41     ` Paolo Bonzini
2016-11-29 10:45       ` Stefan Hajnoczi
2016-11-30 17:41         ` Avi Kivity
2016-12-01 11:45           ` Stefan Hajnoczi
2016-12-01 11:59             ` Avi Kivity
2016-12-01 14:35               ` Paolo Bonzini
2016-12-02 10:12                 ` Stefan Hajnoczi [this message]
2016-12-07 10:38                   ` Avi Kivity
2016-12-07 10:32                 ` Avi Kivity
2016-11-28 20:41   ` Willem de Bruijn
2016-11-29  8:19 ` Christian Borntraeger
2016-11-29 11:00   ` Stefan Hajnoczi
2016-11-29 11:58     ` Christian Borntraeger
2016-11-29 10:32 ` Fam Zheng
2016-11-29 11:17   ` Paolo Bonzini
2016-11-29 13:24     ` Fam Zheng
2016-11-29 13:27       ` Paolo Bonzini
2016-11-29 14:17         ` Fam Zheng
2016-11-29 15:24           ` Andrew Jones
2016-11-29 15:39             ` Fam Zheng
2016-11-29 16:01               ` Andrew Jones
2016-11-29 16:13                 ` Paolo Bonzini
2016-11-29 19:38                   ` Andrew Jones
2016-11-30  7:19                     ` Peter Maydell
2016-11-30  9:05                       ` Andrew Jones
2016-11-30  9:46                         ` Peter Maydell
2016-11-30 14:18                           ` Paolo Bonzini
2016-12-05 11:20                             ` Alex Bennée
2016-11-29 15:45             ` Paolo Bonzini
2016-11-29 20:43       ` Stefan Hajnoczi
2016-11-30  5:42         ` Fam Zheng
2016-11-30  9:38           ` Stefan Hajnoczi
2016-11-30 10:50             ` Fam Zheng
2016-11-30 15:10               ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161202101235.GB14548@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=avi@scylladb.com \
    --cc=axboe@fb.com \
    --cc=borntraeger@de.ibm.com \
    --cc=davidel@xmailserver.org \
    --cc=eliezer.tamir@linux.intel.com \
    --cc=eric.dumazet@gmail.com \
    --cc=famz@redhat.com \
    --cc=hch@lst.de \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).