linux-kernel - Re: [PATCH v4 3/7] acpi-cpufreq: Add support for disabling dynamic overclocking

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:	Sat, 23 Jul 2011 23:42:50 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	cpufreq@...r.kernel.org, davej@...hat.com,
	linux-kernel@...r.kernel.org, borislav.petkov@....com,
	mark.langsdorf@....com, andreas.herrmann3@....com
Subject: Re: [PATCH v4 3/7] acpi-cpufreq: Add support for disabling dynamic overclocking

On Sat, Jul 23, 2011 at 11:33 PM, Matthew Garrett <mjg@...hat.com> wrote:
> On Sat, Jul 23, 2011 at 11:15:02PM -0400, Andy Lutomirski wrote:
>
>> I was curious and looked it up.  Intel SDM volume 3, 14.3.2.1 says:
>>
>> Opportunistic processor performance operation can be disabled by
>> setting bit 38 of
>> IA32_MISC_ENABLE. This mechanism is intended for BIOS only. If
>> IA32_MISC_ENABLE[38] is set, CPUID.06H:EAX[1] will return 0.
>
> Hm. Interesting. The observed behaviour is that it works fine if we
> toggle this ourselves, and I don't remember the version of the docs I
> was looking at adding the BIOS proviso. Having said that...
>
>> System software can temporarily disengage opportunistic processor
>> performance
>> operation by setting bit 32 of the IA32_PERF_CTL MSR (0199H), using a read-
>> modify-write sequence on the MSR.
>
> This complicates things a little, since right now we just write the
> firmware's P state value directly into PERF_CTL. We'd need to add code
> to acpi_cpufreq_target to make sure that it masked that bit off. It's a
> little more awkward, but if we're being told not to do it by just
> hitting the bit in MISC_ENABLE it's probably worth it. I'll try to
> handle that this week.

This way may give the benefit of making it work per core instead of
per package.  The manual is rather unclear on this point.

I actually have a use case for this.  I have a system that keeps a
bunch of cores under moderate load.  I have one thread in particular
that needs to be fast, and I'd like to disable boosting on the other
cores to keep more thermal and power headroom available for the one
thread that cares.

Of course, I can probably accomplish this with scaling_max_freq as well.

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