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

Re: [Xen-devel] Xen on ARM IRQ latency and scheduler overhead



Dario Faggioli <dario.faggioli@xxxxxxxxxx> writes:

> On Fri, 2017-02-17 at 19:44 +0000, Julien Grall wrote:
>> On 02/17/2017 06:40 PM, Dario Faggioli wrote:
>> > Does ARM
>> > have frequency scaling (I did remember something on xen-devel, but
>> > I am
>> > not sure whether it landed upstream)?
>> 
>> I guess you mean the series sent by globallogic ([1])? If so, it was 
>> never upstreamed.
>> 
> Yep, that one. I was quite sure it did not went in, but was in hurry,
> and could not double check the code. Sorry.
>
>> However the frequency scaling may depend on the processor used and 
>> sometimes implemented using big.LITTLE (e.g the task has to switch).
>> 
>> I am not sure why it would matter in this case.
>> 
> It's hard to tell whether or not (and if yes, how much) it matter in
> this specific case. In general, when I was working on squeezing latency
> on bare-metal Linux, disabling scaling was one of the steps.
>
> It depends on quite a few different factors, but, roughly, during the
> time you're idle waiting for the interrupt, you're running at low
> frequency.
>
> When the interrupt comes, what happens depends on the governor, but you
> usually don't immediately jump to the highest frequency, because that
> happens gradually. And if all you do is something quick, in response to
> the timer interrupt (like in this and similar cases), you most likely
> end up doing that running at low frequency, which may impact latency
> (at least the latency of the completion of the work that the timer
> triggered).

Jumping in a little late but thought I'd add my 2c on cpu frequency
control on arm.

Typically, changing frequency requires active participation by a
software agent, e.g., linux. It's not done automagically behind the
scene in hardware. If there are no agents changing frequency, then the
cores run at the frequency they were booted at by the firmware.

When waiting for an event (WFI/WFE) it is unlikely that frequency is
lowered and ramped up on receiving such events. Such behaviour would
need to be implemented as part of the agent controlling the
frequency. Indeed, there have been discussions on implementing such
functionality in linux on certain arm platforms.

>
> But I was also referring to the fact that the app is using some
> hardware counters, and a frequency value for updating them, and for
> converting their value to time. So I was wondering how the fact that
> frequency may be changing dynamically may interact with that (and
> that's because I'm pretty ignorant about ARM internals, I know :-/).

In the absence of a controlling agent, hardware counters should not be
running at variable frequency.

Hope this helps.

Thanks,
Punit

>
> Regards,
> Dario
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.