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

[liu ping fan]

On Mon, Jul 22, 2013 at 5:40 PM, Alex Bligh <address@hidden> wrote:
> Liu,
>
>
> --On 22 July 2013 12:38:02 +0800 liu ping fan <address@hidden> 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.

> Secondly, I don't understand this point. Let's assume we keep alarm_timers.
> The timers run from signals at the moment (under POSIX) and could easily
> run in their own thread. They synchronise with the thread waiting on poll
> by using the event notifiers. Why do you need to have multiple threads
> dealing with timers? At most one new thread (and quite possibly zero)
> should be sufficient, as all they need to do is write() to the correct
> notifier FD, which will end the relevant poll. Of course if we delete

Different AioContext may have different deadline, so I separate the alarm_timers

Regards,
Pingfan
> alarm_timers this is all irrelevant.
>
> --
> Alex Bligh