From: Fam Zheng <famz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
Eliezer Tamir <eliezer.tamir@linux.intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, Jens Axboe <axboe@fb.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Davide Libenzi <davidel@xmailserver.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] Linux kernel polling for QEMU
Date: Tue, 29 Nov 2016 22:17:46 +0800 [thread overview]
Message-ID: <20161129141746.GA2043@lemon> (raw)
In-Reply-To: <04fa01e1-0613-fc14-527b-e3432c6fec1a@redhat.com>
On Tue, 11/29 14:27, Paolo Bonzini wrote:
>
>
> On 29/11/2016 14:24, Fam Zheng wrote:
> > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> >>
> >>
> >> On 29/11/2016 11:32, Fam Zheng wrote:
> >>>
> >>> The kernel change will be a new prctl operation (should it be a different
> >>> syscall to extend?) to register a new type of eventfd called "idle eventfd":
> >>>
> >>> prctl(PR_ADD_IDLE_EVENTFD, int eventfd);
> >>> prctl(PR_DEL_IDLE_EVENTFD, int eventfd);
> >>>
> >>> It will be notified by kernel each time when the thread's local core has no
> >>> runnable threads (i.e., entering idle state).
> >>>
> >>> QEMU can then add this eventfd to its event loop when it has events to poll, and
> >>> watch virtqueue/linux-aio memory from userspace in the fd handlers. Effectiely,
> >>> if a ppoll() would have blocked because there are no new events, it could now
> >>> return immediately because of idle_eventfd events, and do the idle polling.
> >>
> >> This has two issues:
> >>
> >> * it only reports the leading edge of single_task_running(). Is it also
> >> useful to stop polling on the trailing edge?
> >
> > QEMU can clear the eventfd right after event firing so I don't think it is
> > necessary.
>
> Yes, but how would QEMU know that the eventfd has fired? It would be
> very expensive to read the eventfd on each iteration of polling.
The idea is to ppoll() the eventfd together with other fds (ioeventfd and
linux-aio etc.), and in the handler, call event_notifier_test_and_clear()
followed by a polling loop for some period.
Fam
>
> Paolo
>
> >> * it still needs a system call before polling is entered. Ideally, QEMU
> >> could run without any system call while in polling mode.
> >>
> >> Another possibility is to add a system call for single_task_running().
> >> It should be simple enough that you can implement it in the vDSO and
> >> avoid a context switch. There are convenient hooking points in
> >> add_nr_running and sub_nr_running.
> >
> > That sounds good!
> >
> > Fam
> >
next prev parent reply other threads:[~2016-11-29 14:17 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
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 [this message]
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=20161129141746.GA2043@lemon \
--to=famz@redhat.com \
--cc=axboe@fb.com \
--cc=borntraeger@de.ibm.com \
--cc=davidel@xmailserver.org \
--cc=eliezer.tamir@linux.intel.com \
--cc=hch@lst.de \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.