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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2013-07-22 06:38, liu ping fan wrote:
> On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh <alex@alex.org.uk> wrote:
>> Liu,
>>
>>
>> --On 21 July 2013 16:42:57 +0800 Liu Ping Fan <qemulist@gmail.com> 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
resolution events. Your last series neglects this. We may need two
versions of timers - or one interface that caters both use cases properly.

Jan

> so it can be AioContext-related. So I have patch2&5.
> --2nd. You want to substitute alarm_timer with timeout of poll.
>     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)
> 
> Anything else?
> 
> Thanks and regards,
> Pingfan
> 
>> --
>> Alex Bligh

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux