Messages in this thread | | | From | Vincent Guittot <> | Date | Fri, 15 Sep 2023 15:20:25 +0200 | Subject | Re: [PATCH 1/4] sched: consolidate and cleanup access to CPU's max compute capacity |
| |
On Thu, 14 Sept 2023 at 22:46, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote: > > On 01/09/2023 15:03, Vincent Guittot wrote: > > Remove struct rq cpu_capacity_orig field and use arch_scale_cpu_capacity() > > instead. > > > > Scheduler uses 3 methods to get access to the CPU's max compute capacity: > > - arch_scale_cpu_capacity(cpu) which is the default way to get CPU's capacity. > > - cpu_capacity_orig field which is periodically updated with > > arch_scale_cpu_capacity(). > > - capacity_orig_of(cpu) which encapsulates rq->cpu_capacity_orig > > > > There is no real need to save the value returned by arch_scale_cpu_capacity() > > in struct rq. arch_scale_cpu_capacity() returns: > > - either a per_cpu variable. > > - or a const value for systems which have only one capacity. > > > > Remove cpu_capacity_orig and use arch_scale_cpu_capacity() everywhere. > > > > No functional changes. > > > > some tests of Arm64: > > small SMP device (hikey): no noticeable changes > > HMP device (RB5): hackbench shows minor improvement (1-2%) > > large smp (thx2): hackbench and tbench shows minor improvement (1%) > > > > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> > > Next to util_fits_cpu() which uses capacity_orig as a local variable > (which is fine) there is sis() referring to capacity_orig in a comment. > > Documentation/scheduler/sched-capacity.rst uses the term `capacity_orig` > in chapter 1.2 to explain the difference between CPU's maximum > (attainable) capacity and capacity as the former reduced by pressure.
ok, I will have a look at those references to capacity_orig
> > Not sure if you want to change those refs as well with this patch? > People might get confused about the term `capacity_orig` pretty soon. > > Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Thanks
| |