Re: [Qemu-devel] [RFC] [PATCHv8 09/30] aio / timers: Add QEMUTimerListGroup and helper functions

[Stefan Hajnoczi <stefanha@redhat.com>]

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