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: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff
Date: Thu, 25 Jul 2013 14:01:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2013-07-25 13:44, Stefan Hajnoczi wrote:
> On Tue, Jul 23, 2013 at 10:51:06AM +0800, liu ping fan wrote:
>> 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?
> 
> It's also unclear to me what you mean, Jan.  Which approach exactly are
> you unhappy with?

"Timer is a concept for timeouts" is either an unfortunate term or
indicates a misunderstanding what timers are used for, also in QEMU. You
may currently see them only in the context of timeouts, but they are
also used for periodic or continuously reprogrammed one-shot guest timers.

Make sure that we can easily extend the timer architecture so that
selected timers can run against their own carrier threads while the rest
sticks with the mainloop or whatever best-effort context, and I'm fine.

> 
> We always invoke timer callbacks from the main loop, there is no
> high-frequency high-priority timer code path,

...yet...

> so I'm not sure what the
> issue is.
> 
> Stefan
> 

Jan

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



reply via email to

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