Re: [PATCH/RFC 0/2] arm64: dts: renesas: Re-add voltages to OPP tables

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

 



Hi Lukasz,

On Mon, Oct 28, 2024 at 2:41 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
> On 10/28/24 11:34, Geert Uytterhoeven wrote:
> > On Fri, Oct 25, 2024 at 5:40 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
> >> On 10/22/24 14:36, Geert Uytterhoeven wrote:
> >>> On Tue, Oct 8, 2024 at 11:14 AM Geert Uytterhoeven
> >>> <geert+renesas@xxxxxxxxx> wrote:
> >>>> When CONFIG_ENERGY_MODEL=y, an error is printed on RZ/G2E and R-Car E3:
> >>>>
> >>>>       cpu cpu0: EM: invalid perf. state: -22
> >>>>
> >>>> This happens because the Operating Points Parameters tables do not list
> >>>> voltages, as they are all identical.  Previously, it was assumed they
> >>>> were optional, and unused, when none of the CPU nodes is tied to a
> >>>> regulator using the "cpu-supply" property.  This assumption turned out
> >>>> to be incorrect, causing the reported error message.
> >>>>
> >>>> This RFC patch series fixes this by adding the missing voltages.
> >>>>
> >>>> Note that the Energy Model calculates energy efficiency by dividing the
> >>>> (estimated) CPU power consumption by CPU core clock frequency.  When all
> >>>> voltages have the same value, the former is proportional to clock
> >>>> frequency, and energy efficiency becomes a constant.  Hence all
> >>>> operating points are considered to have the same efficiency, and the
> >>>> Energy Model always picks the one with the highest clock rate (see also
> >>>> [1]).
> >>>>
> >>>> Alternatively, the Energy Model could be changed to silently ignore OPP
> >>>> tables with missing frequencies.  IMHO this is not an unusual case.
> >>>>
> >>>> Which approach should be taken?
> >>>> Thanks for your comments!
> >>>
> >>> Any comments from the Energy Model and PM people?
> >>
> >> My apologies for delay.
> >>
> >> So you had issue with bogus Voltage values and removed them.
> >>
> >> There is another way to setup EM properly, via DT:
> >> "opp-microwatt" [1].
> >>
> >> That micro watt value won't confuse other subsystems, like
> >> your regulator fwk. It will only be used by the EM fwk.
> >>
> >> This would be an alternative to your voltage values.
> >> Sounds better to you?
> >
> > For opp-microwatt, I do need to know the actual power consumption
> > of the core, right?
>
> Correct. You can try to derived that in a way you did and put below.
> Although, Dhrystone is a synthetic micro-benchmark with small
> impact to data caches, so it will not use much power.

Do you have a suggestion for a better load test? stress-ng?

> > Full system power consumption while running the in-kernel
> > Dhrystones benchmark:
> >
> > 800 MHz: avg 4972,55 mW, stdef 20,474 mW
> > 1000 MHz: avg 5025,93 mW, stdef 18,644 mW
> > 1200 MHz: avg 5059,63 mW, stdef 15,425 mW
>
> Right. From those power values can be try to derive the
> 'CPU only power' values - assuming only one core was
> running the test.
>
> AFAIU you don't have proper DVFS due to missing voltage scaling.

Indeed.

> Therefore...
> Out of that I got these CPU power values:
> 800MHz -> 174mW

=> 217.5 µW/MHz

> 1000MHz -> 212mW

=> 212 µW/MHz

> 1200MHz -> 261mW

=> 217.5 µW/MHz.

So 1000 MHz seems to be the most power-efficient.

> > The system also has test points across a 0.005 Ohm sense resistor in
> > the DVFS power supply line, but no on-board measurement sensor (like
> > the MAX9611 on Salvator-X(S)), so I haven't measured anything
> > there yet.

I'll try to do some measurements at these test points.

> >> Do you know from /sys/kernel/debug/energy_model/
> >> the current power values?
> >
> > With this series applied:
> >
> > root@ebisu:~# grep -r . /sys/kernel/debug/energy_model/
> > /sys/kernel/debug/energy_model/cpu0/ps:1200000/inefficient:0
> > /sys/kernel/debug/energy_model/cpu0/ps:1200000/performance:1024
> > /sys/kernel/debug/energy_model/cpu0/ps:1200000/cost:3443
> > /sys/kernel/debug/energy_model/cpu0/ps:1200000/power:352643
> > /sys/kernel/debug/energy_model/cpu0/ps:1200000/frequency:1200000
> > /sys/kernel/debug/energy_model/cpu0/ps:1000000/inefficient:1
> > /sys/kernel/debug/energy_model/cpu0/ps:1000000/performance:853
> > /sys/kernel/debug/energy_model/cpu0/ps:1000000/cost:3445
> > /sys/kernel/debug/energy_model/cpu0/ps:1000000/power:293869
> > /sys/kernel/debug/energy_model/cpu0/ps:1000000/frequency:1000000
> > /sys/kernel/debug/energy_model/cpu0/ps:800000/inefficient:1
> > /sys/kernel/debug/energy_model/cpu0/ps:800000/performance:682
> > /sys/kernel/debug/energy_model/cpu0/ps:800000/cost:3447
> > /sys/kernel/debug/energy_model/cpu0/ps:800000/power:235095
> > /sys/kernel/debug/energy_model/cpu0/ps:800000/frequency:800000
> > /sys/kernel/debug/energy_model/cpu0/flags:0x3
> > /sys/kernel/debug/energy_model/cpu0/cpus:0-1
>
> Those power values listed above look a bit higher, but they
> could be more related to a benchmark which utilized caches
> and more parts of the CPU. I don't know if you had chance to
> see some of my presentations on Linux conferences, where
> I show how much power can vary in different scenarios at
> the same frequency...

Thanks, I will have a look...

> TLDR; it can be even 1.8x comparing to Dhrystone.
>
> So would say it's OK for you to put either your Dhrystone
> power results, or these one from EM dump (probably from
> some more heavy benchmark then set into DT coefficient
> to derive them in OPP fwk).

Given the figures above (212 µW/MHz vs. 217.5 µW/MHz) using rather
coarse measurements are already close or identical, they might end up
being identical, and then we're back at square zero, where EM cannot
do anything?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux