From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7oJt-0000rW-10 for qemu-devel@nongnu.org; Fri, 09 Aug 2013 11:09:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7oJm-00067W-UE for qemu-devel@nongnu.org; Fri, 09 Aug 2013 11:09:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7oJm-00067P-H2 for qemu-devel@nongnu.org; Fri, 09 Aug 2013 11:09:30 -0400 Date: Fri, 9 Aug 2013 17:09:19 +0200 From: Stefan Hajnoczi Message-ID: <20130809150919.GB9270@stefanha-thinkpad.redhat.com> References: <1375998147-24292-1-git-send-email-alex@alex.org.uk> <1375998147-24292-10-git-send-email-alex@alex.org.uk> <5204BE51.70006@redhat.com> <66F49369-34D8-4F02-87B7-946095072EBD@alex.org.uk> <5204FE33.1060306@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5204FE33.1060306@redhat.com> Subject: Re: [Qemu-devel] [RFC] [PATCHv8 09/30] aio / timers: Add QEMUTimerListGroup and helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , liu ping fan , qemu-devel@nongnu.org, Alex Bligh , MORITA Kazutaka , rth@twiddle.net On Fri, Aug 09, 2013 at 04:35:31PM +0200, Paolo Bonzini wrote: > Il 09/08/2013 16:27, Alex Bligh ha scritto: > > Paolo, > > > >>> diff --git a/include/qemu/timer.h b/include/qemu/timer.h > >>> index 1baa0e2..3b46f60 100644 > >>> --- a/include/qemu/timer.h > >>> +++ b/include/qemu/timer.h > >>> @@ -52,8 +52,10 @@ typedef enum { > >>> > >>> typedef struct QEMUClock QEMUClock; > >>> typedef struct QEMUTimerList QEMUTimerList; > >>> +typedef QEMUTimerList *QEMUTimerListGroup[QEMU_CLOCK_MAX]; > >> > >> Please wrap this in a struct for easier future extensibility. > > > > OK > > > >> I'm not a big fan of the TimerListGroup name, but I cannot think of > >> anything better... > > > > Ditto > > > >> ... except if we get rid of TimerListGroup completely and put it in > >> AioContext. To do so, we can have _two_ AioContexts in main-loop.c. > >> One is for the block layer, the other is only used for timers. Later we > >> could move bottom halves from the first to the second, too. > > > > I don't really want to do this, or at least I don't want to do it yet. > > Partly my concern is about initialising a dummy AioContext and having > > it hang around. Partly the point is that the timer stuff is meant to > > work without any AioContexts. > > Perhaps, but do we really need it to work outside AioContexts? Using a > second AioContext for bottom halves has been mentioned for a while. It > would fix issues where a bottom half runs spuriously before QEMU starts, > just because something uses qemu_aio_wait(). Extending the same > approach to timers is natural. > > At some point Stefan was planning to add a per-BlockDriverState > AioContext. Once that is done, using two different AioContext for > "default block layer context" and "default main loop" context would be > very easily done. The model I'm going for is that the user can configure how many event loop threads to use. Then they can bind a -drive to a specific event loop thread and it will operate in that AioContext. So it isn't quite a per-BDS AioContext model but perhaps I'll hit something which does require per-BDS AioContexts. History has shown the Paolo's ideas here tend to be a good solution, even when I initially tried another approach. Stefan