From: Ingo Molnar <mingo@kernel.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, viresh.kumar@linaro.org,
lukasz.luba@arm.com, ionela.voinescu@arm.com,
pierre.gondois@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-pm@vger.kernel.org, conor.dooley@microchip.com,
suagrfillet@gmail.com, ajones@ventanamicro.com, lftan@kernel.org
Subject: Re: [PATCH v2 1/6] sched: consolidate and cleanup access to CPU's max compute capacity
Date: Mon, 9 Oct 2023 13:01:12 +0200 [thread overview]
Message-ID: <ZSPdeMzCzDRCIqUw@gmail.com> (raw)
In-Reply-To: <20231009103621.374412-2-vincent.guittot@linaro.org>
* Vincent Guittot <vincent.guittot@linaro.org> 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>
> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>
> ---
> Documentation/scheduler/sched-capacity.rst | 13 +++++++------
> kernel/sched/core.c | 2 +-
> kernel/sched/cpudeadline.c | 2 +-
> kernel/sched/deadline.c | 4 ++--
> kernel/sched/fair.c | 18 ++++++++----------
> kernel/sched/rt.c | 2 +-
> kernel/sched/sched.h | 6 ------
> kernel/sched/topology.c | 7 +++++--
> 8 files changed, 25 insertions(+), 29 deletions(-)
I've applied patch #1 to tip:sched/core, thanks!
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, viresh.kumar@linaro.org,
lukasz.luba@arm.com, ionela.voinescu@arm.com,
pierre.gondois@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-pm@vger.kernel.org, conor.dooley@microchip.com,
suagrfillet@gmail.com, ajones@ventanamicro.com, lftan@kernel.org
Subject: Re: [PATCH v2 1/6] sched: consolidate and cleanup access to CPU's max compute capacity
Date: Mon, 9 Oct 2023 13:01:12 +0200 [thread overview]
Message-ID: <ZSPdeMzCzDRCIqUw@gmail.com> (raw)
In-Reply-To: <20231009103621.374412-2-vincent.guittot@linaro.org>
* Vincent Guittot <vincent.guittot@linaro.org> 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>
> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>
> ---
> Documentation/scheduler/sched-capacity.rst | 13 +++++++------
> kernel/sched/core.c | 2 +-
> kernel/sched/cpudeadline.c | 2 +-
> kernel/sched/deadline.c | 4 ++--
> kernel/sched/fair.c | 18 ++++++++----------
> kernel/sched/rt.c | 2 +-
> kernel/sched/sched.h | 6 ------
> kernel/sched/topology.c | 7 +++++--
> 8 files changed, 25 insertions(+), 29 deletions(-)
I've applied patch #1 to tip:sched/core, thanks!
Ingo
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, sudeep.holla@arm.com,
gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, viresh.kumar@linaro.org,
lukasz.luba@arm.com, ionela.voinescu@arm.com,
pierre.gondois@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-pm@vger.kernel.org, conor.dooley@microchip.com,
suagrfillet@gmail.com, ajones@ventanamicro.com, lftan@kernel.org
Subject: Re: [PATCH v2 1/6] sched: consolidate and cleanup access to CPU's max compute capacity
Date: Mon, 9 Oct 2023 13:01:12 +0200 [thread overview]
Message-ID: <ZSPdeMzCzDRCIqUw@gmail.com> (raw)
In-Reply-To: <20231009103621.374412-2-vincent.guittot@linaro.org>
* Vincent Guittot <vincent.guittot@linaro.org> 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>
> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>
> ---
> Documentation/scheduler/sched-capacity.rst | 13 +++++++------
> kernel/sched/core.c | 2 +-
> kernel/sched/cpudeadline.c | 2 +-
> kernel/sched/deadline.c | 4 ++--
> kernel/sched/fair.c | 18 ++++++++----------
> kernel/sched/rt.c | 2 +-
> kernel/sched/sched.h | 6 ------
> kernel/sched/topology.c | 7 +++++--
> 8 files changed, 25 insertions(+), 29 deletions(-)
I've applied patch #1 to tip:sched/core, thanks!
Ingo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-09 11:01 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 10:36 [PATCH v2 0/6] consolidate and cleanup CPU capacity Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` [PATCH v2 1/6] sched: consolidate and cleanup access to CPU's max compute capacity Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 11:01 ` Ingo Molnar [this message]
2023-10-09 11:01 ` Ingo Molnar
2023-10-09 11:01 ` Ingo Molnar
2023-10-09 11:04 ` [tip: sched/core] sched/topology: Consolidate and clean up access to a " tip-bot2 for Vincent Guittot
2023-10-09 10:36 ` [PATCH v2 2/6] topology: add a new arch_scale_freq_reference Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-11 10:27 ` Pierre Gondois
2023-10-11 10:27 ` Pierre Gondois
2023-10-11 10:27 ` Pierre Gondois
2023-10-11 13:48 ` Vincent Guittot
2023-10-11 13:48 ` Vincent Guittot
2023-10-11 13:48 ` Vincent Guittot
2023-10-18 11:06 ` Lukasz Luba
2023-10-18 11:06 ` Lukasz Luba
2023-10-18 11:06 ` Lukasz Luba
2023-10-09 10:36 ` [PATCH v2 3/6] cpufreq: use the fixed and coherent frequency for scaling capacity Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 11:01 ` Viresh Kumar
2023-10-09 11:01 ` Viresh Kumar
2023-10-09 11:01 ` Viresh Kumar
2023-10-18 11:16 ` Lukasz Luba
2023-10-18 11:16 ` Lukasz Luba
2023-10-18 11:16 ` Lukasz Luba
2023-10-09 10:36 ` [PATCH v2 4/6] cpufreq/schedutil: use a fixed reference frequency Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-18 11:21 ` Lukasz Luba
2023-10-18 11:21 ` Lukasz Luba
2023-10-18 11:21 ` Lukasz Luba
2023-10-09 10:36 ` [PATCH v2 5/6] energy_model: " Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-15 5:50 ` kernel test robot
2023-10-18 9:16 ` Lukasz Luba
2023-10-18 9:16 ` Lukasz Luba
2023-10-18 9:16 ` Lukasz Luba
2023-10-09 10:36 ` [PATCH v2 6/6] cpufreq/cppc: set the frequency used for capacity computation Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-09 10:36 ` Vincent Guittot
2023-10-11 10:27 ` Pierre Gondois
2023-10-11 10:27 ` Pierre Gondois
2023-10-11 10:27 ` Pierre Gondois
2023-10-11 14:25 ` Vincent Guittot
2023-10-11 14:25 ` Vincent Guittot
2023-10-11 14:25 ` Vincent Guittot
2023-10-16 12:12 ` Ionela Voinescu
2023-10-16 12:12 ` Ionela Voinescu
2023-10-16 12:12 ` Ionela Voinescu
2023-10-16 15:32 ` Vincent Guittot
2023-10-16 15:32 ` Vincent Guittot
2023-10-16 15:32 ` Vincent Guittot
2023-10-17 9:02 ` Ionela Voinescu
2023-10-17 9:02 ` Ionela Voinescu
2023-10-17 9:02 ` Ionela Voinescu
2023-10-17 13:41 ` Vincent Guittot
2023-10-17 13:41 ` Vincent Guittot
2023-10-17 13:41 ` Vincent Guittot
2023-10-18 11:27 ` [PATCH v2 0/6] consolidate and cleanup CPU capacity Lukasz Luba
2023-10-18 11:27 ` Lukasz Luba
2023-10-18 11:27 ` Lukasz Luba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZSPdeMzCzDRCIqUw@gmail.com \
--to=mingo@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=conor.dooley@microchip.com \
--cc=dietmar.eggemann@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=ionela.voinescu@arm.com \
--cc=juri.lelli@redhat.com \
--cc=lftan@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=lukasz.luba@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=suagrfillet@gmail.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.