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

[liu ping fan]

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?

Thx&regards,
Pingfan

> 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