From owner-freebsd-stable@FreeBSD.ORG Sun Mar 22 16:35:55 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1A31782 for ; Sun, 22 Mar 2015 16:35:55 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFD5D3B6 for ; Sun, 22 Mar 2015 16:35:55 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2MGZiqa030172 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Mar 2015 09:35:45 -0700 Message-ID: <550EEF60.20406@freebsd.org> Date: Sun, 22 Mar 2015 09:35:44 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kevin Oberman , Ian Smith Subject: Re: dev.cpu.0.freq disapeared References: <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> In-Reply-To: X-Sonic-CAuth: UmFuZG9tSVbhPMFUT6CXMEJEmJ6IXoKpJUW1iSErtxDHtbslkW6fx6ykBOEe3901CB8Exg4rDfBGInj2DyFBflD9EN+zEm7Vq0tVG88m08w= X-Sonic-ID: C;ELKFfLHQ5BGPlNBwQIsAyQ== M;xg4JfbHQ5BGPlNBwQIsAyQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Peter Jeremy , FreeBSD Stable ML , Dmitry Sivachenko X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 16:35:55 -0000 On 03/22/15 09:29, Kevin Oberman wrote: > On Sun, Mar 22, 2015 at 7:11 AM, Ian Smith > wrote: > > Dmitry Sivachenko wrote: > > On 22 марта 2015 г., at 8:53, Peter Jeremy > > wrote: > > On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko > > 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 > ="isa" hint.attimer.0.port="0x40" > hint.attimer.0.irq="0" 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@gmail.com