Date: Sun, 22 Mar 2015 09:29:41 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: Peter Jeremy <peter@rulingia.com>, FreeBSD Stable ML <stable@freebsd.org>, Dmitry Sivachenko <trtrmitya@gmail.com>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: dev.cpu.0.freq disapeared Message-ID: <CAN6yY1sE8u9oJvo%2BB_0=oAdOPhN3LLnbtQcHLPOjRSvN6yy54Q@mail.gmail.com> In-Reply-To: <550ECD9D.2030108@nimnet.asn.au> References: <EE8D6553-4319-4CE1-8F73-3244C49F454C@gmail.com> <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 22, 2015 at 7:11 AM, Ian Smith <smithi@nimnet.asn.au> wrote: > Dmitry Sivachenko wrote: > >> On 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2015 =D0=B3., at 8:53, Peter Jeremy= <peter@rulingia.com> wrote: >>> >>> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko <trtrmitya@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=3D"GenuineIntel" Id=3D0x206c2 Family=3D0x6 >>>> Model=3D0x2c Stepping=3D2 >>>> >>> ... >>> >>>> 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 fi= le 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, followin= g >> 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 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- 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=3D"is= a" >> hint.attimer.0.port=3D"0x40" hint.attimer.0.irq=3D"0" hint.wbwd.0.at=3D"= isa" >> +hint.acpi_throttle.0.disabled=3D"1" +hint.p4tcc.0.disabled=3D"1" >> >> >> If I remove that hint.p4tcc.0.disabled=3D"1" from device.hints, >> dev.cpu.0.freq appears back again. >> > > 'Trivial re-enabling' would be adding hint.p4tcc.0.disabled=3D"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 expecte= d >> 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=3D1 hint.acpi_throttle.0.disabled=3D1 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. 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@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1sE8u9oJvo%2BB_0=oAdOPhN3LLnbtQcHLPOjRSvN6yy54Q>