qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] [PATCHv8 09/30] aio / timers: Add QEMUTimerListGr


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] [PATCHv8 09/30] aio / timers: Add QEMUTimerListGroup and helper functions
Date: Fri, 09 Aug 2013 17:15:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

Il 09/08/2013 17:09, Stefan Hajnoczi ha scritto:
>> 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.

Yes, this is really what I meant.  I wasn't sure exactly how to describe
it.  In any case, it is not really related to nested event loops.  It
even seems like an extension of what I'm asking Alex to do.  In
principle you could have many AioContexts (plus the one for
qemu_new_timer aka qemu_timer_new) but put all of them in the main iothread.

Paolo

> So it isn't quite a per-BDS AioContext model but perhaps I'll hit
> something which does require per-BDS AioContexts.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]