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.
