dev.cpu.0.freq disapeared
Nathan Whitehorn
nwhitehorn at freebsd.org
Sun Mar 22 16:35:55 UTC 2015
On 03/22/15 09:29, Kevin Oberman wrote:
> On Sun, Mar 22, 2015 at 7:11 AM, Ian Smith <smithi at nimnet.asn.au
> <mailto:smithi at nimnet.asn.au>> wrote:
>
> Dmitry Sivachenko wrote:
>
> On 22 марта 2015 г., at 8:53, Peter Jeremy
> <peter at rulingia.com <mailto:peter at rulingia.com>> wrote:
>
> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko
> <trtrmitya at gmail.com <mailto:trtrmitya at gmail.com>> wrote:
>
> I have a machine with the following processor:
>
> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
> (2400.14-MHz
> K8-class CPU) Origin="GenuineIntel" Id=0x206c2
> Family=0x6 Model=0x2c Stepping=2
>
> ...
>
> After I upgraded to 10.1-STABLE #0 r279956, this
> sysctl disapeared. % sysctl dev.cpu.0.freq sysctl:
> unknown oid 'dev.cpu.0.freq': No such file or directory %
>
>
> What OIDs do you have? Does dev.cpu.0 exist? How about
> dev.cpu?
>
>
> dev.cpu.0 does exist.
>
>
> It could be helpful to show all of:
>
> % sysctl dev.cpu
> % sysctl dev.est # if you have that?
> % sysctl -a | grep freq | grep -v time
>
> both before and after re-enabling p4tcc.
>
> I found the problematic change:
>
> Author: nwhitehorn Date: Sun Jan 11 17:10:07 2015 New
> Revision: 276986 URL:
> https://svnweb.freebsd.org/changeset/base/276986
>
> Log: MFC r265329: Disable ACPI and P4TCC throttling by
> default, following discussion on freebsd-current. These CPU
> speed control techniques are usually unhelpful at best. For
> now, continue building the relevant code into GENERIC so that
> it can trivially be re-enabled
> at runtime if anyone wants it.
>
> Modified: stable/10/sys/amd64/conf/GENERIC.hints
> ==============================================================================
> --- stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11
> 17:00:24 2015 (r276985) +++
> stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11 17:10:07
> 2015 (r276986) @@ -31,3 +31,5 @@ hint.attimer.0.at
> <http://hint.attimer.0.at>="isa" hint.attimer.0.port="0x40"
> hint.attimer.0.irq="0" hint.wbwd.0.at
> <http://hint.wbwd.0.at>="isa"
> +hint.acpi_throttle.0.disabled="1" +hint.p4tcc.0.disabled="1"
>
>
> If I remove that hint.p4tcc.0.disabled="1" from device.hints,
> dev.cpu.0.freq appears back again.
>
>
> 'Trivial re-enabling' would be adding hint.p4tcc.0.disabled="0" to
> /boot/loader.conf. This seems very strange though, if it really is
> due solely to disabling p4tcc and acpi_throttle.
>
> I am using dev.cpu.0.freq to ensure that processor is running
> at expected frequency (with some buggy BIOSes or buggy BIOS
> options combinations it is possible to end up with machine
> running at half frequency).
>
>
> Are you not running powerd? Of course powerd won't start if it can't
> get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or
> highest freqs. Once FreeBSD starts, BIOS settings should have little
> do with it, AFAIK, except how they might set freq before powerd
> starts.
>
> Does it really hurt to have this sysctl available? Why it was
> disabled by default?
>
>
> It's a long story; (a) short story is using it to vary freqs doesn't
> save any power, but makes powerd work harder matching freq to load.
>
> (I am not discussing hint.acpi_throttle.0.disabled here, just
> hint.p4tcc.0.disabled).
>
>
> Some or many systems will use ACPI throttling instead if p4tcc (or
> equivalent on AMD or other processors) isn't enabled, so they both
> need disabling to run 'raw' EST or equivalent.
>
> A link to a verbose boot would be good, before and after if possible.
>
> cheers, Ian
>
>
> First, my system which does have powerd and dev.cpu.0.freq has been
> running without p4tcc for years. From my loader.conf file:
> # Disable CPU throttling
> hint.p4tcc.0.disabled=1
> hint.acpi_throttle.0.disabled=1
> But I do have EST. If that is missing, so is dev.cpu.0.freq. Do you
> see "sysctl dev.est"? It should include freq_settings for each CPU.
>
> Processors older than P4s did not have the more efficient TCC
> capability, so the more primitive throttling was used. By default,
> when TCC is available, it is used. If not, throttling is used. Of
> course, almost all i386 and all amd64 processors should have TCC, so,
> unless TCC is disabled, throttling is not used.
>
> TCC is the Thermal Control Circuit. Note that it was designed and
> intended to be a rather heavy handed way to prevent overheating of the
> CPU. It was never intended nor is it useful for power management.
> Worse, it can interfere with C-states, by far the most effective power
> management tool available, at least when used the way powerd uses it.
> This "unpleasant" interaction that lead to system lock-up resulted in
> C-states being disabled, just adding insult to injury. Head should now
> have the "correct" settings with throttling and p4tcc disabled and
> both performance and economy_cx_lowest defaulting to Cmax.
>
> The real issue appears to be that some systems seem to not have EST. I
> am suspicious that this may be the case for some or all non-i386/amd64
> processors. Even if EST is not available, turning on TCC or throttling
> is not going to save any power. It just means that the system will not
> have the ability to have multiple CPU frequencies.
Thanks for the nice summary. We do in fact have non-x86 CPUs with real
power management and EST-equivalent clock changing that are supported by
FreeBSD. I think the P4-era stuff is the only hardware that uses
throttling/TCC-type logic.
-Nathan
> If you want more details on power issues in FreeBSD, I would point you
> to the excellent article by mav@ at
> https://wiki.freebsd.org/TuningPowerConsumption. He covers all of the
> research I did independently back when I was at Lawrence Berkeley.Lab
> back in the 90s and extends it to cover most modern technologies not
> available when I did my research.
> --
> Kevin Oberman, Network Engineer, Retired
> E-mail: rkoberman at gmail.com <mailto:rkoberman at gmail.com>
More information about the freebsd-stable
mailing list