Re: [PATCH v4 14/16] sched/core: uclamp: request CAP_SYS_ADMIN by default

From: Patrick Bellasi
Date: Mon Sep 24 2018 - 13:19:30 EST


On 24-Sep 18:26, Peter Zijlstra wrote:
> On Mon, Sep 24, 2018 at 04:14:00PM +0100, Patrick Bellasi wrote:
>
> > ... still it's difficult to give a precise definition of knee point,
> > unless you know about platforms which have a sharp change in energy
> > efficiency.
> >
> > The only cases we know about are those where:
> >
> > A) multiple frequencies uses the same voltage, e.g.
> >

On a side note, the following plots represents ee^-1, or eventually,
the P on the y axise... my bad.... but you got the meaning anyway ;)

> >
> > ^ *
> > | Energy O
> > | efficiency O+
> > | O |
> > | O* |
> > | O** |
> > | O** O*** |
> > | + O** O**** |
> > | | O** O***** |
> > | | O** |
> > | | + |
> > | | Same V | Increasing V |
> > +---+----------+----------------------+----------->
> > | | | Frequency
> > L M H
> >
> > B) there is a big frequency gap between low frequency OPPs and high
> > frequency OPPs, e.g.
> >
> > O
> > ^ **+
> > | Energy ** |
> > | efficiency ** |
> > | ** |
> > | ** |
> > | ** |
> > | ** |
> > | ** |
> > | O** |
> > | O******+ |
> > |O******* | |
> > | | |
> > ++--------------+------------------+------>
> > | | | Frequency
> > L M H
> >
> >
> > In case A, all the OPPs left of M are dominated by M in terms
> > of energy efficiency and normally they should be never used.
> > Unless you are under thermal constraints and you still want to keep
> > your code running even if at a lower rate and energy efficiency.
> > At this point, however, you already invalidated all the OPPs right of
> > M and, on the remaining, you still struggle do define the knee point.
> >
> > In case B... I'm wondering it such a conf even makes sense ;)
> > Is there really some platform out there with such a "non homogeneously
> > distributed" set of available frequencies ?
>
> Well, the curve is a second or third order polynomial (when V~f -> fV^2
> -> f^3), so it shoots up at some point. There's not really anything you
> can do about that. But if you're willing to put in active cooling and
> lots of energy, you can make it go fast :-)

Sure... until you don't melt the silicon you can push the frequency.

However, if you are going for such aggressive active cooling, perhaps
your interest for energy efficiency it's already a very low priority
goal.

> Therefore I was thinking:
>
> > Maybe we can define a threshold
> > for a "EE derivative ratio", but it will still be quite arbitrary.
>
> Because up until de/df=.5 we gain more performance than we loose ee.

You mean up until de < df ?

IOW... the threshold should be de == df => 45deg tangent ?

> But I might not have appreciated the fact that when we work with
> imaginary cost units that skews the .5.

The main skew IMO comes from the fact the energy efficiency
"tipping point" is very much application / user specific...
and it can also change depending on the usage scenario for the
same user and platform.

--
#include <best/regards.h>

Patrick Bellasi