qemu-devel
[Top][All Lists]
Advanced

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

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


From: liu ping fan
Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff
Date: Tue, 23 Jul 2013 10:53:26 +0800

On Mon, Jul 22, 2013 at 6:18 PM, liu ping fan <address@hidden> wrote:
> 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.
>>
The scenior I can figure out is if adopting timeout of poll, then when
changing the deadline, we need to invoke poll, and set the new
timeout, right?

Regards,
Pingfan
> 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



reply via email to

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