linux-kernel - Re: [PATCH] cpufreq: pass policy to ->get() driver callback

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:	Thu, 10 Sep 2015 23:59:07 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
	Kristen Carlson Accardi <kristen@...ux.intel.com>,
	open list <linux-kernel@...r.kernel.org>,
	Sudeep Holla <sudeep.holla@....com>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Michael Turquette <mturquette@...libre.com>
Subject: Re: [PATCH] cpufreq: pass policy to ->get() driver callback

On Thursday, September 10, 2015 06:52:22 AM Viresh Kumar wrote:
> On 10-09-15, 03:41, Rafael J. Wysocki wrote:

[cut]

> 
> > Overall, we need to talk about the design aspect of cpufreq, because there
> > are much more significant issues in it than things like this one.
> 
> I agree.

OK

Adding Mark and Srinivas who may be interested in this to CC.

Why don't we start with listing all of the cpufreq's shortcomings we'd like
to address, then try to sort out conflicting items and come up with a list
of tasks to complete?

To me, the most painful thing ATM is that cpufreq cannot use timer functions
to carry out state transitions even if the underlying driver could request
state to be changed from interrupt context.  IMO, we should utilize the
capabilities of the hardware where possible and only add overhead where it
is necessary.

Speaking of which I'm concerned that we're adding overhead for systems that
don't need software synchronization of state transitions (the "one CPU per
policy" case).  I'm not sure how much of that is really happening, but it
would be review the code from that angle and streamline things where
policy objects are not shared.

The locking is overdesigned and overkill (and you know that already), but
if we do the above, it'll be more strarightforward to simplify it IMO.

Finally, the initialization is questionable and in particular the fact that we
need to call the driver's ->init at least once to get policy->cpus populated.
This shouldn't be necessary, as that information reflects the topology of
the system and shouldn't depend on which driver is in use really.

Please let me know what your pain points are. :-)

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/