linux-kernel - Re: [PATCH v9 15/15] OPTIONAL: cpufreq: dt: Register an Energy Model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Nov 2018 10:01:44 +0000
From:   Quentin Perret <quentin.perret@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     peterz@...radead.org, rjw@...ysocki.net,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        gregkh@...uxfoundation.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, tkjos@...gle.com,
        joel@...lfernandes.org, smuckle@...gle.com,
        adharmap@...eaurora.org, skannan@...eaurora.org,
        pkondeti@...eaurora.org, juri.lelli@...hat.com,
        edubezval@...il.com, srinivas.pandruvada@...ux.intel.com,
        currojerez@...eup.net, javi.merino@...nel.org
Subject: Re: [PATCH v9 15/15] OPTIONAL: cpufreq: dt: Register an Energy Model

Hi Viresh,

On Tuesday 20 Nov 2018 at 11:49:25 (+0530), Viresh Kumar wrote:
> On 19-11-18, 14:18, Quentin Perret wrote:
> >  static int cpufreq_init(struct cpufreq_policy *policy)
> >  {
> > +	struct em_data_callback em_cb = EM_DATA_CB(of_est_power);
> >  	struct cpufreq_frequency_table *freq_table;
> >  	struct opp_table *opp_table = NULL;
> >  	struct private_data *priv;
> > @@ -160,7 +203,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> >  	unsigned int transition_latency;
> >  	bool fallback = false;
> >  	const char *name;
> > -	int ret;
> > +	int ret, nr_opp;
> >  
> >  	cpu_dev = get_cpu_device(policy->cpu);
> >  	if (!cpu_dev) {
> > @@ -237,6 +280,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> >  		ret = -EPROBE_DEFER;
> >  		goto out_free_opp;
> >  	}
> > +	nr_opp = ret;
> >  
> >  	if (fallback) {
> >  		cpumask_setall(policy->cpus);
> > @@ -280,6 +324,8 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> >  	policy->cpuinfo.transition_latency = transition_latency;
> >  	policy->dvfs_possible_from_any_cpu = true;
> >  
> > +	em_register_perf_domain(policy->cpus, nr_opp, &em_cb);
> > +
> >  	return 0;
> >  
> >  out_free_cpufreq_table:
> 
> I haven't gone deep into the series, but why don't we need something
> like em_unregister_perf_domain()? That can be used if the cpufreq
> driver goes away. Else loading/unloading/loading the cpufreq driver
> may register the perf-domain callback again.

Right, that's a good point. Registering the perf-domain multiple times
is harmless -- all but the first registration will be ignored. That
_should_ be documented somewhere in patch 03. I'll double check and add
the doc if that's not the case.

The overall idea so far has been to keep the EM framework as simple as
possible. We allocate the EM once and it stays in memory forever. That
makes it really easy for the scheduler (for instance) to manipulate
pointers to perf domains without having to worry about them being
unregistered. We could definitely do something smarter to
register/unregister the PDs dynamically using refcount or something,
but hopefully this is something we can do later, if need be.

Thanks,
Quentin