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

[Julien Grall <julien.grall@linaro.org>]

Hi,

First of all, thank you Oleksandr for starting a thread around CPUFreq 
support.

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@linaro.org> 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?

Have you explored some other possibility to save power? I am asking 
that, because the topic is fairly new with Xen.

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...).

Cheers,

-- 
Julien Grall

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