linux-kernel - Re: [PATCH 0/11] cpufreq: governor: ondemand/conservative data structures rework

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: <20160204054049.GX3469@vireshk>
Date:	Thu, 4 Feb 2016 11:10:49 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	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 0/11] cpufreq: governor: ondemand/conservative data
 structures rework

On 04-02-16, 00:12, Rafael J. Wysocki wrote:
> Hi,
> 
> A few days ago I looked at the common code used by the ondemand and conservative
> governors because of the deadlock issue that Viresh has addressed recently
> (http://marc.info/?l=linux-pm&m=145450832814058&w=4) and it occurred to me
> that the whole thing was really too tangled and might be made easier to follow
> at least.  I started to work on this and ended up with the following series.
> 
> I'm not really going to stop here, but first, I'd like to let everybody know
> that this is happening and second, I'll need to rebase these patches on the
> ones from Viresh (in the series linked above), but that may take some time
> and I don't want to sit on them for all that long.
> 
> Overall, I'd like the governor code to be cleaner and easier to follow, so we can
> move at least some parts of governor work to utilization update callbacks (invoked
> by the scheduler) or to at least to irq_work so as to reduce the usage of process
> context in cpufreq to absolute minimum.  That's the plan for the future, but for
> now this is just a major cleanup.
> 
> [1/11] Clean up the way in which the default and fallback governors are set up.
> [2/11] Use a common global mutex for dbs_data protection.
> [3/11] Use common global pointer to dbs_data for system-wide governors.

Hi Rafael,

I have some very basic doubts on 2nd and 3rd patch, and so have
stopped reviewing after that because there is too much dependency I
believe on these two.

I will review the rest, if my concerns on the earlier ones are
incorrect.

-- 
viresh