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, 28 Nov 2013 14:09:59 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Dirk Brandewie <dirk.brandewie@...il.com>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Patch Tracking <patches@...aro.org>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nishanth Menon <nm@...com>, Carlos Hernandez <ceh@...com>
Subject: Re: [PATCH V2] cpufreq: Make sure CPU is running on a freq from freq-table

On Thursday, November 28, 2013 08:50:20 AM Viresh Kumar wrote:
> On 28 November 2013 01:51, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> > I have a concern that on some systems you can't really say what frequency
> > you're running at the moment, however.
> 
> Which ones? I know ACPI tries to play smart by handling the frequency stuff
> itself by marking CPUs not-related to each other for the kernel where they
> might actually be sharing clock line... But probably in these cases as well,
> atleast the cpufreq core should believe that it is running on a valid frequency
> even if actual hardware is running at something different..
> 
> Any other platforms you are aware of that implement ->target/target_index
> and where we can't say what freq are they running at?

acpi-cpufreq is one at least.

Anyway, this isn't about ACPI or anything like that, but hardware.  Generally
speaking, on modern Intel hardware the processor itself chooses the frequency
to run at and it may do that behind your back.  Moreover, it can choose a
frequency different from the one you asked for.  And it won't choose one that
it can't run at for that matter. :-)

Overall, I don't believe that the problem you're trying to address is relevant
for any non-exotic x86 hardware.

> > So there should be a flag for
> > drivers indicating whether or not frequencies (or operation points in
> > general) are directly testable and the check should only be done for
> > the drivers with the flag set.
> 
> Probably a flag with properties exactly opposite to what you mentioned,
> so that we don't need to modify most of the drivers..

That would work too if you prefer it.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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