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

[Stefan Hajnoczi]

On Tue, Jul 23, 2013 at 10:51:06AM +0800, liu ping fan wrote:
> On Mon, Jul 22, 2013 at 2:28 PM, Jan Kiszka <address@hidden> wrote:
> > On 2013-07-22 06:38, liu ping fan wrote:
> >> On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh <address@hidden> wrote:
> >>> Liu,
> >>>
> >>>
> >>> --On 21 July 2013 16:42:57 +0800 Liu Ping Fan <address@hidden> 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".
> >>>
> >>>
> >>> Stefan & Paolo did not like that method much, so I did a third method
> >>> (posted yesterday) suggested by Stefan which adds a clock to AioContext 
> >>> (to
> >>> which timers can be attached), deletes ALL the alarm_timer stuff (which 
> >>> was
> >>> very cathartic), uses timeouts on the g_poll, and adds ppoll where this is
> >>> available. Series at:
> >>>  http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg03334.html
> >>>
> >>> I suspect this also overlaps with your code.
> >>>
> >>> So now we have 3 methods to do similar things!
> >>>
> >>> One advantage of my approach is that it removes more code than it adds
> >>> (by quite a margin). However, alarm timers could have been left in.
> >>> What's the advantage in giving an AioContext its own alarm timer as
> >>> opposed to just its own clock?
> >>>
> >> I read your second series, and try to summary the main different between 
> >> us.
> >> Please correct me, if I misunderstood something.
> >> --1st. You try to create a separate QemuClock for AioContext.
> >>     I think QemuClock is the clock event source and we have three
> >> classic with fine definition. They should be qemu-wide for time
> >> measurement.  On the other handler, timer is  a concept for timeout,
> >
> > Timers, as used in QEMU, are not only for "unimportant" and
> > unlikely-to-fire timeouts. They are also for potential high-rate, high
> 
> Sorry, but can not catch the point.  QemuTimer is used to trigger
> something, so the process can be delayed for some reason. For high
> resolution events, do we go directly to QEMUClock, which fall back on
> host's hpet? And the use case is just for get the time stamp, NOT for
> trigger?

It's also unclear to me what you mean, Jan.  Which approach exactly are
you unhappy with?

We always invoke timer callbacks from the main loop, there is no
high-frequency high-priority timer code path, so I'm not sure what the
issue is.

Stefan