[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |