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

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



On Fri, Nov 17, 2017 at 6:41 PM, Andre Przywara
<andre.przywara@xxxxxxxxxx> wrote:
> Hi,
Hi Andre

>
> ....
>
>>> So Xen does not need to throw in its own ideas here. Which would avoid
>>> some of the hard problems we encountered.
>> I got all your point.
>> Just question. Why does existing CPUFreq on x86 have own logic? Do we have
>> something yet another on ARM that having own logic in Xen doesn't make
>> any sense?
>
> That's a good question. From quickly poking some people in #xendevel,
> Julien learnt that CPUFreq on x86 might not really work well or at least
> not as expected.
> So the benefit is not even clear there. It just went in the tree once,
> and possibly nobody ever revisited it since.
> And even if there were good reasons back then, modern CPUs tend to be
> quite different in terms of power characteristics.
Thank you for the clarification. It is clear now.

>
> ....
>
>>> 0. Decide whether CPUFreq justifies 1.-4. in the first place.
>> Sure,
>>> 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.
>> Well, I think I will be able to provide some numbers when a firmware,
>> which runs on the SoC
>> I am using, is ready. Actually, currently I have an emulator without
>> any real freq/volt changes.
>
> Yes, some actual numbers would very much help the case. I don't think
> you need very sophisticated equipment, just running a workload once with
> and once without CPUFreq and compare the power consumption would be a
> good start. This could be as easy as measuring the (m)Wh consumed with
> some wall-plug type power meter. I use some very cheap USB power
> meter[1], which I put between the PSU and some single board computer to
> get an idea on what the power consumption is. Surely not really
> reliable, but better than nothing.
Thank you for the pointer. I am afraid, it is going to be a question how measure
power consumption on my developing board) Most effectively would be
measure a current
via CPU power rail(s).

I think, I could collect some statistics (Px vs time) for different
use-cases using xenpm tool.
Where "without CPUFReq" means just to set "userspace" governor and
exactly the same frequency,
on which we come from the firmware.

>
>>> 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?
>> As I said before, we are interesting in purely embedded use-cases
>> where power consumption is a question.
>> If you know how to save power without having CPUFreq involved I would
>> appreciate the pointers.
>
> As Julien said, I guess idling and CPU offlining/CPU suspend (via PSCI)
> would be a good start to look at. You could try to get some numbers on
> this as well.
Yes.

>
> Cheers,
> Andre.
>
> [1]
> https://www.ebay.co.uk/itm/USB-Charger-Doctor-Voltage-Current-Meter-Mobile-Battery-Tester-Power-Detector-UK/263220956905
>
>>> 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.
>> OK.
>>



-- 
Regards,

Oleksandr Tyshchenko

_______________________________________________
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®.