mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Valentin Schneider <vschneid@redhat.com>
To: Shrikanth Hegde <sshegde@linux.vnet.ibm.com>,
	mingo@redhat.com, peterz@infradead.org,
	vincent.guittot@linaro.org
Cc: sshegde@linux.vnet.ibm.com, dietmar.eggemann@arm.com,
	linux-kernel@vger.kernel.org, ionela.voinescu@arm.com,
	qperret@google.com, srikar@linux.vnet.ibm.com,
	mgorman@techsingularity.net, mingo@kernel.org,
	pierre.gondois@arm.com, yu.c.chen@intel.com,
	tim.c.chen@linux.intel.com, pauld@redhat.com,
	lukasz.luba@arm.com, linux-doc@vger.kernel.org,
	bsegall@google.com, linux-eng@arm.com
Subject: Re: [PATCH v5 2/2] sched/topology: change behaviour of sysctl sched_energy_aware based on the platform
Date: Wed, 04 Oct 2023 13:27:50 +0200	[thread overview]
Message-ID: <xhsmhttr6oceh.mognet@vschneid.remote.csb> (raw)
In-Reply-To: <20230929155209.667764-3-sshegde@linux.vnet.ibm.com>

On 29/09/23 21:22, Shrikanth Hegde wrote:
> +static bool sched_is_eas_possible(const struct cpumask *cpu_mask)
> +{
> +	bool any_asym_capacity = false;
> +	struct cpufreq_policy *policy;
> +	struct cpufreq_governor *gov;
> +	int i;
> +
> +	/* EAS is enabled for asymmetric CPU capacity topologies. */
> +	for_each_cpu(i, cpu_mask) {
> +		if (per_cpu(sd_asym_cpucapacity, i)) {

Lockdep should complain here in the sysctl path - this is an RCU-protected
pointer.

rcu_access_pointer() should do since you're not dereferencing the pointer.

> +			any_asym_capacity = true;
> +			break;
> +		}
> +	}

> @@ -231,6 +295,15 @@ static int sched_energy_aware_handler(struct ctl_table *table, int write,
>               return -EPERM;
>
>       ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);

Shouldn't this happen after we check sched_is_eas_possible()? Otherwise
AFAICT a write can actually happen despite !sched_is_eas_possible().

> +	if (!sched_is_eas_possible(cpu_active_mask)) {
> +		if (write) {
> +			return -EOPNOTSUPP;
> +		} else {
> +			*lenp = 0;
> +			return 0;
> +		}
> +	}

But now this is making me wonder, why not bite the bullet and store
somewhere whether we ever managed to enable EAS? Something like so?
(I didn't bother making this yet another static key given this is not a hot
path at all)
---
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index e0b9920e7e3e4..abd950f434206 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -209,6 +209,7 @@ sd_parent_degenerate(struct sched_domain *sd, struct sched_domain *parent)
 #if defined(CONFIG_ENERGY_MODEL) && defined(CONFIG_CPU_FREQ_GOV_SCHEDUTIL)
 DEFINE_STATIC_KEY_FALSE(sched_energy_present);
 static unsigned int sysctl_sched_energy_aware = 1;
+static bool __read_mostly sched_energy_once;
 static DEFINE_MUTEX(sched_energy_mutex);
 static bool sched_energy_update;
 
@@ -230,6 +231,15 @@ static int sched_energy_aware_handler(struct ctl_table *table, int write,
 	if (write && !capable(CAP_SYS_ADMIN))
 		return -EPERM;
 
+	if (!sched_energy_once) {
+		if (write) {
+			return -EOPNOTSUPP;
+		} else {
+			*lenp = 0;
+			return 0;
+		}
+	}
+
 	ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
 	if (!ret && write) {
 		state = static_branch_unlikely(&sched_energy_present);
@@ -340,6 +350,8 @@ static void sched_energy_set(bool has_eas)
 		if (sched_debug())
 			pr_info("%s: starting EAS\n", __func__);
 		static_branch_enable_cpuslocked(&sched_energy_present);
+		// Record that we managed to enable EAS at least once
+		sched_energy_once = true;
 	}
 }
 


  parent reply	other threads:[~2023-10-04 11:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-29 15:52 [PATCH v5 0/2] sched: EAS changes for EM complexity and sysctl Shrikanth Hegde
2023-09-29 15:52 ` [PATCH v5 1/2] sched/topology: Remove EM_MAX_COMPLEXITY limit Shrikanth Hegde
2023-09-29 15:52 ` [PATCH v5 2/2] sched/topology: change behaviour of sysctl sched_energy_aware based on the platform Shrikanth Hegde
2023-10-03  9:20   ` Pierre Gondois
2023-10-03 12:27     ` Shrikanth Hegde
2023-10-04 11:27   ` Valentin Schneider [this message]
2023-10-04 14:59     ` 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=xhsmhttr6oceh.mognet@vschneid.remote.csb \
    --to=vschneid@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-eng@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pierre.gondois@arm.com \
    --cc=qperret@google.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=sshegde@linux.vnet.ibm.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=yu.c.chen@intel.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®