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:	Tue, 15 Sep 2015 13:24:31 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
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 10-09-15, 23:59, Rafael J. Wysocki wrote:
> Adding Mark and Srinivas who may be interested in this to CC.

         Mike ? :)

> 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?

Yeah, sounds like a good plan.

> 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.

Absolutely right.

> 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.

Maybe, maybe not.. Probably we need to look at exact code paths for
that and then decide.. But we should get this simplified if we can.

> 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.

Locking is really bad today.. I wrote lots of patches for that, but
never got them upstreamed. I should try doing that after pushing the
remaining govenor patches ..

> 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.

I am not sure how feasible it will be get the topology information in
a generic way, but if we can, we should.

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

There were few minor things as well, I already have some code for
them:
- Dividing the really large cpufreq.[h|c] files into better, more
  readable blocks. For example, one file for sysfs stuff alone..
- Some sort of test suite for cpufreq. I wrote one, which contains
  most of the cases, which helped us fixing governor races:

  https://git.linaro.org/people/viresh.kumar/cpufreq-tests.git

  But, these are plain bash scripts. Not really tied to any kernel
  internal test suite. Which suite should I adapt them for ?

-- 
viresh
--
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/