On Wed, 10 Jan 2024 at 14:51, Dietmar Eggemann <dietmar.eggemann@xxxxxxx> wrote: > > On 09/01/2024 15:30, Vincent Guittot wrote: > > On Tue, 9 Jan 2024 at 12:22, Dietmar Eggemann <dietmar.eggemann@xxxxxxx> wrote: > >> > >> On 08/01/2024 14:48, Vincent Guittot wrote: > >>> Aggregate the different pressures applied on the capacity of CPUs and > >>> create a new function that returns the actual capacity of the CPU: > >>> get_actual_cpu_capacity() > >> > >> function name scaling > >> > >> (1) arch_scale_cpu_capacity() - uarch > >> > >> (2) get_actual_cpu_capacity() - hw + cpufreq/thermal of (1) > >> > >> (3) capacity_of() - rt (rt/dl/irq) of (2) (used by fair) > >> > >> Although (1) - (3) are very close to each other from the functional > > > > I don't get your point as name of (1) and (3) have not been changed by the patch > > That's true. But with capacity_orig_of() for (1), we had some coherence > in the naming scheme of those cpu_capacity related functions (1) - (3). > which helps when trying to understand the code. > > I can see that actual_capacity_of() (2) sounds awful though. > > >> standpoint, their names are not very coherent. > >> > >> I assume this makes it hard to understand all of this when reading the > >> code w/o knowing these patches before. > >> > >> Why is (2) tagged with 'actual'? > > > > This is the actual max compute capacity of the cpu at now i.e. > > possibly reduced because of temporary frequency capping > > Will the actual max compute capacity also depend on 'user space system > pressure' later, i.e. on 'permanent' frequency capping? yes it will > > > So (2) equals (1) minus temporary performance capping and (3) > > additionally subtracts the time used by other class to (2) > > OK. > > A coherent set of those tags even reflected in those getters would help > but can be done later too.
