linux-kernel - Re: [PATCH 2/11] cpufreq: governor: Use common mutex for dbs

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]

Message-ID: <CAJZ5v0iHX0OO+dJRJvT=8Q7YixCK1bySCfUmYJrLJGfA-6XFdQ@mail.gmail.com>
Date:	Fri, 5 Feb 2016 04:15:13 +0100
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	"Rafael J. Wysocki" <rafael@...nel.org>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Juri Lelli <juri.lelli@....com>,
	Steve Muckle <steve.muckle@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>
Subject: Re: [PATCH 2/11] cpufreq: governor: Use common mutex for dbs_data protection

On Fri, Feb 5, 2016 at 4:06 AM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Fri, Feb 5, 2016 at 3:59 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
>> On 04-02-16, 17:46, Rafael J. Wysocki wrote:
>>> On Thu, Feb 4, 2016 at 6:09 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
>>> > On 04-02-16, 00:16, Rafael J. Wysocki wrote:
>>> >> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>> >>
>>> >> Every governor relying on the common code in cpufreq_governor.c
>>> >> has to provide its own mutex in struct common_dbs_data.  However,
>>> >> those mutexes are never used at the same time
>>> >
>>> > Why do you think so? I thought they can always be used in parallel.
>>> >
>>> > Consider 2 or more policies, one can have ondemand as the governor,
>>> > whereas other one can have conservative.
>>> >
>>> > If CPUs go online/offline or if governors are switching in parallel,
>>> > then cpufreq_governor_dbs() can very much run in parallel for ondemand
>>> > and conservative.
>>> >
>>> > Or am I missing something here ?
>>>
>>> Well, so perhaps the changelog is inaccurate.
>>>
>>> However, what's wrong with using a single mutex then?
>>
>> You are killing the possibility of running the code faster. Consider
>> this:
>> - A 16 policy system with N CPUs in every policy (IBM has something
>>   similar only :) )..
>> - 4 policies using ondemand, 4 using conservative, 4 using powersave
>>   and 4 with performance.
>> - Now if we try to change governors for all of them in parallel, only
>>   one will be done at a time and others have to wait for this
>>   BIG-kernel lock.
>
> And why is this a big problem, actually?  Why do we want the switching
> of governors to be that efficient?

In any case, we're talking about having one lock instead of two, mind
you (out of the tree things don't count), because performance and
powersave don't even use the code in question.

I'm not really sure how much of a difference that would make on a
really big system.

Thanks,
Rafael