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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, Jul 22, 2013 at 06:18:03PM +0800, liu ping fan wrote:
> On Mon, Jul 22, 2013 at 5:40 PM, Alex Bligh <alex@alex.org.uk> wrote:
> > Liu,
> >
> >
> > --On 22 July 2013 12:38:02 +0800 liu ping fan <qemulist@gmail.com> wrote:
> >
> >> 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,
> >> so it can be AioContext-related. So I have patch2&5.
> >
> >
> > Yes and no. QEMUClock is not a clock source. QEMUClock /has/ a clock
> > source, and more than one QEMUClock can share the same clock source.
> >
> Supposed the case sync the time across iothread/vcpu/dataplane, the
> vm_clock is a unique interface for all of them.
> 
> > QEMUClock does have its own list of timers, and so if you only
> > want to run a subset of timers in aio_poll (which is I believe the
> > requirement so not to change the behaviour of existing timers),
> > you need a separate QEMUClock.
> >
> > The approach I took (StefanH's idea) was to put a QEMUClock into
> > each AioContext. Arguably you might want to put a set of 3 QEMUClock's
> > into each AioContext, one for each clock source.
> >
> > QEMUClock itself is very lightweight as far as I can tell.
> >
> I think the weight is not the point here, rather, the concept.
> >
> >> --2nd. You want to substitute alarm_timer with timeout of poll.
> >
> >
> > Correct.
> >
> >
> >>     I try to trigger each specified thread when its deadline comes.
> >> But unfortunately, the signal can not be delivered to the specified
> >> thread directly, and I need timerfd for each AioContext. (If we can
> >> have the equivalent on other platform)
> >
> >
> > Firstly, I can't see the advantage of keeping the alarm_timer stuff around
> > at all if we can delete it. Save, of course, that on systems that don't
> > have ppoll or equivalent you lose sub-millisecond timing by deleting them.
> >
> I do not think it very clearly. But the final aim is to associate an
> eventfd with deadline, and attach the eventfd to g_poll.  For linux,
> it can be easily achieved by timerfd,  for other posix, what I can
> thought till now is to distinguish the source of timer in signal
> handler, and revoke a eventfd (stands for deadline) on AioContext.
> I am not sure whether this is better than timeout of poll.

Using eventfds for timeouts is more heavy-weight.  It means a file
descriptor per timeout and more system calls.   We already need to do
the poll(2) system call, we might as well make use of the timeout
argument.

Stefan