From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBkGt-0008TA-FU for qemu-devel@nongnu.org; Tue, 29 Nov 2016 10:24:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBkGp-0005hO-Er for qemu-devel@nongnu.org; Tue, 29 Nov 2016 10:24:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53964) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBkGp-0005gV-6M for qemu-devel@nongnu.org; Tue, 29 Nov 2016 10:24:35 -0500 Date: Tue, 29 Nov 2016 16:24:28 +0100 From: Andrew Jones Message-ID: <20161129152428.4w6c6fuate4eouc5@kamzik.brq.redhat.com> References: <20161124151225.GA11963@stefanha-x1.localdomain> <20161129103236.GE15786@lemon> <14abb3dd-b639-3c31-cade-073fff209ca6@redhat.com> <20161129132354.GF15786@lemon> <04fa01e1-0613-fc14-527b-e3432c6fec1a@redhat.com> <20161129141746.GA2043@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161129141746.GA2043@lemon> Subject: Re: [Qemu-devel] Linux kernel polling for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Paolo Bonzini , Eliezer Tamir , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Jens Axboe , Christian Borntraeger , Stefan Hajnoczi , Davide Libenzi , Christoph Hellwig On Tue, Nov 29, 2016 at 10:17:46PM +0800, Fam Zheng wrote: > 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 > > > > While we have a ppoll audience, another issue with the current polling is that we can block with an infinite timeout set (-1), and it can actually end up being infinite, i.e. vcpus will never run again. I'm able to exhibit this with kvm-unit-tests. For these rare cases where no other timeout has been selected, shouldn't we have a default timeout? Anyone want to pick a number? I have a baseless compulsion to use 10 ms... Thanks, drew