Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

On Fri, Nov 17, 2017 at 4:01 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> Hi,
Hi, Julien.

>
> First of all, thank you Oleksandr for starting a thread around CPUFreq
> support.
Thank you for the valued comments.

>
> On 11/16/2017 05:04 PM, Andre Przywara wrote:
>>
>> On 16/11/17 14:57, Oleksandr Tyshchenko wrote:
>>>
>>> On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara
>>> <andre.przywara@xxxxxxxxxx> wrote:
>>> Anyway, I think we should go step-by-step.
>>> If community agreed that CPUFreq feature in Xen on ARM was needed and
>>> SCPI/SCMI based approach
>>> was the right thing to do in general I would stick to next taking into
>>> the account Andre's suggestions
>>> regarding some guest input:
>>>
>>> 1. Xen do have CPUFreq logic. It measures CPUs utilization by itself.
>>> 2. In addition it can collect OPP change requests from the guests:
>>>    - There are some politics describing which guest is allowed to send
>>> OPP change request.
>>>    - Of course, involved guests have CPUFreq enabled. All we need is
>>> these OPP change requests don't lead to
>>>      any physical changes and be picked up by Xen. Here we could use
>>> Andre's idea here (SCPI CPUFreq + SMC mailbox with hvc method).
>>> 3. Xen makes a decision based on the whole system status it measures
>>> periodically and guests input (OPP change requests) if present.
>>> 4. Xen actually issues command to change the CPU frequency (sends OPP
>>> change request to SCP).
>>>
>>> How does it sound?
>>
>>
>> 0. Decide whether CPUFreq justifies 1.-4. in the first place. That
>> sounds like a lot of work and code, so we should be sure it's worth it.
>>
>> I wonder if you could provide some input, ideally measurements on the
>> actual power savings CPUFreq provides.
>>
>> Does the wish to have CPUFreq purely come from some "tick-the-box"
>> exercise? As in: We have it on native Linux, so we need it in Xen?
>>
>> What power savings can we expect from CPUFreq? Can those possible
>> savings be transferred into a virtualized environment at all? And do
>> those saving justify all the extra code in Xen?
>>
>> I think those questions need to be answered first, then we can discuss
>> about the implementation details.
>
>
> I am going to throw a bit more ideas. From the discussion, it look like to
> me the story is around power saving when using Xen. Am I right?
Yes.

>
> Have you explored some other possibility to save power? I am asking that,
> because the topic is fairly new with Xen.
As for me, no, I haven't.

>
> Once area where power could be saved is the idle loop (see idle_loop in
> arch/arm/domain.c). At the momment only WFI is used. It would be possible to
> go in deeper low-power state by using PSCI.
>
> Similarly, the virtual PSCI implementation for suspend is quite simple. You
> could potentially use those information to decide what to do with the pCPU
> (suspend, turning off...).
Is vPSCI implementation already present? If so, could you point me
some pointers to look at?

>
> Cheers,
>
> --
> Julien Grall

What I was thinking too is "boot time".

For example, there is strict boot time requirement for some
embedded/industrial system powered by Xen hypervisor.
So the whole system should up and running as soon as possible.
Together with other boot time optimization techniques the CPU boost
feature (if present) can help here.
Usually firmware sets some initial frequency (possibly nominal
frequency, possibly, the highest frequency,
I am not really sure, what "boot" frequencies are across other ARM
SoCs), which is used until CPUFreq comes into play.
And If we don't have CPUFreq in system, we can't set the highest(or
even turbo) frequency in firmware (or in Xen before starting dom0) to
speed up booting.
Because there is nothing is the system who will scale the CPU
frequency down then, and it is may be "not safe" from the silicon
viewpoint as well as "not optimal" from the power consumption
viewpoint
to run at such high frequency "all the time".

-- 
Regards,

Oleksandr Tyshchenko

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