linux-kernel - Re: [RFC][PATCH] sched: Optimize cpufreq_update

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] [day] [month] [year] [list]

Date:   Fri, 19 Mar 2021 20:50:18 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, linux-kernel@...r.kernel.org,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [RFC][PATCH] sched: Optimize cpufreq_update_util

On 19-03-21, 15:35, Rafael J. Wysocki wrote:
> On Friday, March 19, 2021 8:37:51 AM CET Viresh Kumar wrote:
> > On 18-03-21, 22:28, Peter Zijlstra wrote:
> > > Also, is there a lock order comment in cpufreq somewhere?
> > 
> > I don't think so.
> > 
> > > I tried
> > > following it, but eventually gave up and figured 'asking' lockdep was
> > > far simpler.
> > 
> > This will get called from CPU's online/offline path at worst, nothing more.
> 
> I'm not sure if I understand you correctly, but for completeness the callback
> is also set/unset on driver registration and governor switch.

Right, I believe that those cases don't have any specific locking constraints
and so scheduler code doesn't need to worry about them. cpuslocked stuff needs
to be considered though.

> > > +static void cpufreq_update_optimize(void)
> > > +{
> > > +	struct update_util_data *data;
> > > +	cpu_util_update_f func = NULL, dfunc;
> > > +	int cpu;
> > > +
> > > +	for_each_online_cpu(cpu) {
> > > +		data = per_cpu(cpufreq_update_util_data, cpu);
> > > +		dfunc = data ? READ_ONCE(data->func) : NULL;
> > > +
> > > +		if (dfunc) {
> > > +			if (!func)
> > > +				func = dfunc;
> > > +			else if (func != dfunc)
> > > +				return;
> > > +		} else if (func)
> > > +			return;
> > > +	}
> > 
> > So there is nothing cpufreq specific IIRC that can help make this better, this
> > is basically per policy.
> 
> Well, in some cases the driver knows that there will never be more that 1 CPU
> per policy and so schedutil will never use the "shared" variant.
> 
> For instance, with intel_pstate all CPUs will always use the same callback.

Right, only for single policy cases we can have some optimization (though I
don't feel its worth here) as this isn't going to happen in hotpath.

-- 
viresh