[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180619091841.GD9208@codeaurora.org>
Date: Tue, 19 Jun 2018 14:48:41 +0530
From: Pavan Kondeti <pkondeti@...eaurora.org>
To: Quentin Perret <quentin.perret@....com>
Cc: peterz@...radead.org, rjw@...ysocki.net,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, mingo@...hat.com,
dietmar.eggemann@....com, morten.rasmussen@....com,
chris.redpath@....com, patrick.bellasi@....com,
valentin.schneider@....com, vincent.guittot@...aro.org,
thara.gopinath@...aro.org, viresh.kumar@...aro.org,
tkjos@...gle.com, joelaf@...gle.com, smuckle@...gle.com,
adharmap@...cinc.com, skannan@...cinc.com, juri.lelli@...hat.com,
edubezval@...il.com, srinivas.pandruvada@...ux.intel.com,
currojerez@...eup.net, javi.merino@...nel.org
Subject: Re: [RFC PATCH v3 10/10] arch_topology: Start Energy Aware Scheduling
On Mon, May 21, 2018 at 03:25:05PM +0100, Quentin Perret wrote:
<snip>
> +static void start_eas_workfn(struct work_struct *work);
> +static DECLARE_WORK(start_eas_work, start_eas_workfn);
> +
> static int
> init_cpu_capacity_callback(struct notifier_block *nb,
> unsigned long val,
> @@ -204,6 +209,7 @@ init_cpu_capacity_callback(struct notifier_block *nb,
> free_raw_capacity();
> pr_debug("cpu_capacity: parsing done\n");
> schedule_work(&parsing_done_work);
> + schedule_work(&start_eas_work);
> }
>
> return 0;
> @@ -249,6 +255,19 @@ static void parsing_done_workfn(struct work_struct *work)
> free_cpumask_var(cpus_to_visit);
> }
>
> +static void start_eas_workfn(struct work_struct *work)
> +{
> + /* Make sure the EM knows about the updated CPU capacities. */
> + rcu_read_lock();
> + em_rescale_cpu_capacity();
> + rcu_read_unlock();
> +
> + /* Inform the scheduler about the EM availability. */
> + cpus_read_lock();
> + rebuild_sched_domains();
> + cpus_read_unlock();
> +}
Rebuilding the sched domains is unnecessary for the platform that don't have
energy-model. In fact, we can completely avoid scheduling this work.
There seems to be a sysfs interface exposed by this driver to change cpu_scale.
Should we worry about it? I don't know what is the usecase for changing the
cpu_scale from user space.
Are we expecting that the energy-model is populated by this time? If it is
not, should not we build the sched domains again after the energy-model is
populated?
Thanks,
Pavan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Powered by blists - more mailing lists