linux-kernel - Re: [PATCH 00/11] cpufreq: Keep policy->freq

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: <2735911.VQvHH3XKf9@vostro.rjw.lan>
Date:	Fri, 03 Jun 2016 03:43:11 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	Kevin Hilman <khilman@...nel.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Kukjin Kim <kgene@...nel.org>, Sekhar Nori <nsekhar@...com>,
	Steven Miao <realmz6@...il.com>,
	Steve Muckle <steve.muckle@...aro.org>
Subject: Re: [PATCH 00/11] cpufreq: Keep policy->freq_table sorted

On Friday, June 03, 2016 05:31:34 AM Viresh Kumar wrote:
> On 02-06-16, 22:35, Rafael J. Wysocki wrote:
> > Quoting from this very cover letter "This change allows us to remove
> > the (duplicate) sorted-freq-table, which
> > was added by following series:", so why to add it in the first place?
> 
> Okay, that's fine.
> 
> > Besides, there already is a number of tables (per policy which in some
> > important cases pretty much means per CPU) in cpufreq that contain
> > more-or-less the same information.  For example, if acpi-cpufreq is in
> > use, the ACPI layer has a table coming from _PSS, the driver creates
> > freq_table to pass to the core and there is an additional one for the
> > stats.  And your series adds one more just so it is ordered.  Come on.
> 
> Of course.
> 
> > If you want to clean that up, fine, but please don't do that in a
> > hurry.  Let's talk about it a bit more without sending any more
> > patches in that area for the time being.
> 
> Okay, I will send all the fixes that you can apply cleanly now in a
> separate set.

Thanks!

> So, yeah, I get your overall concern. What about this:
> - A single patchset to make sure the current policy->freq_table is
>   always sorted in Ascending order of frequencies.

Be careful here.  acpi-cpufreq sorts the table in the descending order
and at least acpi_cpufreq_fast_switch() assumes that.

> - And this sorting will be done per policy only when the policy is
>   first created.
> - Which would eventually mean merging this series with the [v2 0/2]
>   one.
> 
> Will that work ?

Well, it may. :-)

I would like you to talk to Steve and agree on the approach, including which
changes to make first, though.  You are both from Linaro after all ...

Thanks,
Rafael