Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

[Stefan Hajnoczi]

On Sun, Jul 21, 2013 at 04:42:57PM +0800, Liu Ping Fan wrote:
> Currently, the timers run on iothread within BQL, so virtio-block dataplane 
> can not use throttle,
> as Stefan Hajnoczi pointed out in his patches to port dataplane onto block 
> layer.(Thanks, Stefan)
> To enable this feature, I plan to enable timers to run on AioContext's thread.
> And maybe in future, hpet can run with its dedicated thread too.
> 
> Also, I see Alex Bligh is on the same effort by another method,(it is a good 
> idea) 
>   "[RFC] aio/async: Add timed bottom-halves".
> So I think it is better to post my series for discussion, although I have not 
> thought
> very clearly point, e.g. sigaction 
> 
> This series ports two parts of timer stuff onto AioContext: alarm timer and 
> timer list.
> Currently I worked based on Stefanha's git tree
>        https://github.com/stefanha/qemu.git dataplane-block-layer.
> 
> ---
> Open issue:
>   The thread safe problem on timer list. To resolve that, I plan to adopt the 
> bh model.
> (Not sure about this, maybe Stefan's solution in another thread is better)  
> Although leave most of the race issue unresolved, patch 4 has tried to fix 
> one of
> them as Jan Kiszka points out that vm_clock can be read outside BQL, thanks 
> Jan :)

Thanks for sharing this series.

I think Paolo's idea of getting rid of alarm timers is a good one.  We
end up with less code and fewer system calls.  The only issue is timer
resolution and at least on Linux we can use ppoll(2).

Alex Bligh's series gives each AioContext its own rt_clock.  This avoids
the need for synchronization in the simple case.  If we require timer
access between threads then we really need to synchronize.

You pointed out in another email that vm_clock stops when the guest is
paused.  I think we can find a solution for I/O throttling and QED,
which use vm_clock in the block layer.  Note that block jobs already use
rt_clock.

I'm in favor of Alex Bligh's series rather than continuing to use alarm
timers.

Stefan