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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <11470100.cEo24Tpcgr@vostro.rjw.lan>
Date:	Thu, 10 Sep 2015 03:41:45 +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>
Subject: Re: [PATCH] cpufreq: pass policy to ->get() driver callback

On Friday, July 31, 2015 04:14:33 PM Viresh Kumar wrote:
> CPUFreq drivers today support ->get(cpu) callback, which returns current
> clock rate of the CPU. The problem with ->get() is that it takes cpu
> number as parameter and this unnecessarily makes things complex.
> 
> Firstly the core gets the cpu number by doing operation 'policy->cpu' on
> the policy and then many drivers

I see one.  That unfortunately is the acpi-cpufreq driver, but it still is one.

Well, cpufreq_generic_get() does _get_raw(), so I suppose acpi-cpufreq may
do that too?

> need to get the policy back and so do
> cpufreq_cpu_get(cpu) on the cpu passed as argument to ->get().
> 
> It would be better if we pass them 'policy' directly and drivers can use
> policy->cpu if that's all they need.

Passing a pointer and dereferencing it is generally less efficient than passing
a number.  Before the patch the core has to do the dereference before calling
->get, so it likely doesn't matter here, but the code churn from this change
is quite substantial and the benefit from it is in the noise IMO.

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.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ