lkml.org 
[lkml]   [2021]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] PM / EM: Inefficient OPPs detection
> > As used in the hot-path, the efficient table is a lookup table, generated
> > dynamically when the perf domain is created. The complexity of searching
> > a performance state is hence changed from O(n) to O(1). This also
> > speeds-up em_cpu_energy() even if no inefficient OPPs have been found.
>
> Interesting. Do you have measurements showing the benefits on wake-up
> duration? I remember doing so by hacking the wake-up path to force tasks
> into feec()/compute_energy() even when overutilized, and then running
> hackbench. Maybe something like that would work for you?
>
> Just want to make sure we actually need all that complexity -- while
> it's good to reduce the asymptotic complexity, we're looking at a rather
> small problem (max 30 OPPs or so I expect?), so other effects may be
> dominating. Simply skipping inefficient OPPs could be implemented in a
> much simpler way I think.
>
> Thanks,
> Quentin

On the Pixel4, I used rt-app to generate a task whom duty cycle is getting
higher for each phase. Then for each rt-app task placement, I measured how long
find_energy_efficient_cpu() took to run. I repeated the operation several
times to increase the count. Here's what I've got:

┌────────┬─────────────┬───────┬────────────────┬───────────────┬───────────────┐
│ Phase │ duty-cycle │ CPU │ w/o LUT │ w/ LUT │ │
│ │ │ ├────────┬───────┼───────┬───────┤ Diff │
│ │ │ │ Mean │ count │ Mean │ count │ │
├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
│ 0 │ 12.5% │ Little│ 10791 │ 3124 │ 10657 │ 3741 │ -1.2% -134ns │
├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
│ 1 │ 25% │ Mid │ 2924 │ 3097 │ 2894 │ 3740 │ -1% -30ns │
├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
│ 2 │ 37.5% │ Mid │ 2207 │ 3104 │ 2162 │ 3740 │ -2% -45ns │
├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
│ 3 │ 50% │ Mid │ 1897 │ 3119 │ 1864 │ 3717 │ -1.7% -33ns │
├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
│ │ │ Mid │ 1700 │ 396 │ 1609 │ 1232 │ -5.4% -91ns │
│ 4 │ 62.5% ├───────┼────────┼───────┼───────┼───────┼───────────────┤
│ │ │ Big │ 1187 │ 2729 │ 1129 │ 2518 │ -4.9% -58ns │
├────────┼─────────────┼───────┼────────┼───────┼───────┼───────┼───────────────┤
│ 5 │ 75% │ Big │ 984 │ 3124 │ 900 │ 3693 │ -8.5% -84ns │
└────────┴─────────────┴───────┴────────┴───────┴───────┴───────┴───────────────┘

Notice:

* The CPU column describes which CPU ran the find_energy_efficient()
function.

* I modified my patch so that no inefficient OPPs are reported. This is to
have a fairer comparison between the original table walk and the lookup
table.

* I removed from the table results that didn't have enough count to be
statistically significant.

--
Vincent.

\
 
 \ /
  Last update: 2021-04-22 17:37    [W:0.568 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site