From: Chen Yu <yu.c.chen@intel.com>
To: Shrikanth Hegde <sshegde@linux.vnet.ibm.com>
Cc: <mingo@redhat.com>, <peterz@infradead.org>,
<vincent.guittot@linaro.org>, <dietmar.eggemann@arm.com>,
<vschneid@redhat.com>, <linux-kernel@vger.kernel.org>,
<ionela.voinescu@arm.com>, <quentin.perret@arm.com>,
<srikar@linux.vnet.ibm.com>, <mgorman@techsingularity.net>,
<mingo@kernel.org>
Subject: Re: [PATCH v2] sched/topology: remove sysctl_sched_energy_aware depending on the architecture
Date: Fri, 1 Sep 2023 17:49:56 +0800 [thread overview]
Message-ID: <ZPGzxEVZhpyZuTvj@chenyu5-mobl2> (raw)
In-Reply-To: <20230901065249.137242-1-sshegde@linux.vnet.ibm.com>
Hi Shrikanth,
On 2023-09-01 at 12:22:49 +0530, Shrikanth Hegde wrote:
> Currently sysctl_sched_energy_aware doesn't alter the said behaviour on
> some of the architectures. IIUC its meant to either force rebuild the
> perf domains or cleanup the perf domains by echoing 1 or 0 respectively.
>
> perf domains are not built when there is SMT, or when there is no
> Asymmetric CPU topologies or when there is no frequency invariance.
> Since such cases EAS is not set and perf domains are not built. By
> changing the values of sysctl_sched_energy_aware, its not possible to
> force build the perf domains. Hence remove this sysctl on such platforms
> that dont support it. Some of the settings can be changed later
> such as smt_active by offlining the CPU's, In those cases if
> build_perf_domains returns true, re-enable the sysctl.
>
> Anytime, when sysctl_sched_energy_aware is changed sched_energy_update
> is set when building the perf domains. Making use of that to find out if
> the change is happening by sysctl or dynamic system change.
>
> Taking different cases:
> Case1. system while booting has EAS capability, sysctl will be set 1. Hence
> perf domains will be built if needed. On changing the sysctl to 0, since
> sched_energy_update is true, perf domains would be freed and sysctl will
> not be removed. later sysctl is changed to 1, enabling the perf domains
> rebuild again. Since sysctl is already there, it will skip register.
>
> Case2. System while booting doesn't have EAS Capability. Later after system
> change it becomes capable of EAS. sched_energy_update is false. Though
> sysctl is 0, will go ahead and try to enable eas. This is the current
> behaviour. if has_eas is true, then sysctl will be registered. After
> that any sysctl change is same as Case1.
>
I think this change makes sense. Just one question for case 2,
sched_energy_update is not strictly tied with sysctl change, right?
sched_energy_update is true in rebuild_sched_domains_energy().
rebuild_sched_domains_energy() will not only be invoked by sysctl
path via sched_energy_aware_handler(), but also by other path, such
as update_scale_freq_invariant(). If the system boots with EAS capability
disabled, then it becomes EAS capable due to the frequency invariant
readiness(cpufreq policy change?), then
cpufreq_notifier(CPUFREQ_CREATE_POLICY) -> init_amu_fie_callback() ->
amu_fie_setup() -> opology_set_scale_freq_source() ->
update_scale_freq_invariant(true) -> rebuild_sched_domains_energy()
Since sched_energy_update is true, the rebuild of perf domain will be skipped(but
actually we want to create it) Please correct me if I miss something.
thanks,
Chenyu
thanks,
Chenyu
next prev parent reply other threads:[~2023-09-01 9:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 6:52 Shrikanth Hegde
2023-09-01 9:49 ` Chen Yu [this message]
2023-09-01 13:08 ` Shrikanth Hegde
2023-09-07 10:21 ` Pierre Gondois
2023-09-07 15:04 ` Chen Yu
2023-09-05 14:03 ` Pierre Gondois
2023-09-05 21:53 ` Tim Chen
2023-09-06 3:21 ` Shrikanth Hegde
2023-09-06 11:35 ` Shrikanth Hegde
2023-09-07 10:34 ` Pierre Gondois
2023-09-13 11:55 ` Shrikanth Hegde
-- strict thread matches above, loose matches on Subject: below --
2023-09-01 6:51 Shrikanth Hegde
2023-09-01 6:57 ` Shrikanth Hegde
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=ZPGzxEVZhpyZuTvj@chenyu5-mobl2 \
--to=yu.c.chen@intel.com \
--cc=dietmar.eggemann@arm.com \
--cc=ionela.voinescu@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=quentin.perret@arm.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=sshegde@linux.vnet.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®