From owner-freebsd-stable@freebsd.org Wed Aug 2 10:30:16 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2E81DCC561 for ; Wed, 2 Aug 2017 10:30:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CB22B83F09 for ; Wed, 2 Aug 2017 10:30:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id CA632DCC560; Wed, 2 Aug 2017 10:30:16 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9D68DCC55F for ; Wed, 2 Aug 2017 10:30:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23E7683F08 for ; Wed, 2 Aug 2017 10:30:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1dcquh-000D5s-Fg; Wed, 02 Aug 2017 13:30:03 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: issues with powerd/freq_levels Date: Wed, 2 Aug 2017 13:30:03 +0300 In-Reply-To: <20170802004343.T6737@sola.nimnet.asn.au> Cc: Kevin Oberman , Karl Denninger , stable@freebsd.org To: Ian Smith References: <8AEC9DBC-BADD-4FB2-8358-DA43F7EF5E68@cs.huji.ac.il> <20170731201323.A6737@sola.nimnet.asn.au> <20170802004343.T6737@sola.nimnet.asn.au> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 10:30:17 -0000 > On 1 Aug 2017, at 20:45, Ian Smith wrote: >=20 > On Mon, 31 Jul 2017 12:03:27 -0700, Kevin Oberman wrote: >> On Mon, Jul 31, 2017 at 3:48 AM, Ian Smith = wrote: >>=20 >>> On Mon, 31 Jul 2017 10:09:11 +0300, Daniel Braniss wrote: >>>=20 >>>> I am trying out PCengines latest apu2 boards, and I just noticed = that >>> with different Freebsd versions I get >>>> different freq_levels, and so when idling, each box (have 5) has a >>> different freq/temperature value, ranging >>>> from 125/69.1C, 600/59.0C to 75/56.0C >>>>=20 >>>> FreeBSD apu-4 11.1-STABLE FreeBSD 11.1-STABLE #5 f565b5a06ab3 (11) = tip: >>> Mon Jul 31 09:36:33 IDT 2017 >>>> apu-4# sysctl dev.cpu.0.freq_levels >>>> dev.cpu.0.freq_levels: 1000/980 800/807 600/609 >>>=20 >>> That looks about right. On a Core2Duo (still on 9.3) I get: >>> dev.est.1.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 >>> dev.est.0.freq_settings: 2401/35000 2400/35000 1600/15000 800/12000 >>> dev.cpu.0.freq_levels: 2401/35000 2400/35000 1600/15000 800/12000 >>> dev.cpu.0.freq: 800 >>>=20 >>> But only because I'd added to /boot/loader.conf: >>>=20 >>> hint.p4tcc.0.disabled=3D1 >>> hint.acpi_throttle.0.disabled=3D1 >>>=20 >>> which became the defaults sometime, maybe not before 11.0? = Otherwise >>> mine would look more similar to the one below, with all 12.5% = increments >>> in frequency enabled, which doesn't actually save any power at all. >>>=20 >>>> FreeBSD apu-5 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 = 21e9d1ca9b80 >>> (11) tip: Tue May 30 11:51:48 IDT 2017 >>>> apu-5# sysctl dev.cpu.0.freq_levels >>>> dev.cpu.0.freq_levels: 1000/966 875/845 800/795 700/695 600/600 = 525/525 >>> 450/450 375/375 300/300 225/225 150/150 75/75 >>>=20 >>> Looks like either p4tcc or acpi_throttle is enabled? See = cpufreq(4). >>> As above, these don't buy you anything but extra busyness for = powerd. >>>=20 >>> Also noticed that the (nice, low!) milliwatt figures for = 1000/800/600 >>> freqs are a bit different to the -stable one. Slightly Different = model? >>>=20 >>>> FreeBSD apu-1 10.3-STABLE FreeBSD 10.3-STABLE #4 267788fd852c (10) = tip: >>> Tue Jan 10 09:09:00 IST 2017 >>>> apu-1# sysctl dev.cpu.0.freq_levels >>>> dev.cpu.0.freq_levels: 1000/-1 875/-1 750/-1 625/-1 500/-1 375/-1 >>> 250/-1 125/-1 >>>=20 >>> And that looks like est(4) isn't enabled/attaching at all .. see = dmesg >>> on all of these for clues. >>>=20 >>>> so, any ideas as to what is going on? >>>=20 >>> Pure guesswork on experience with older versions, I'm not up to = date. >>>=20 >>=20 >> Very odd. Are all systems running identical CPUs and BIOSes? = Identical >> loader and sysctl configurations? Look at /var/rn/dmesg.boot for CPU >> information. Is EST being detected? It used to be early in the boot >> process, but is now fairly late. (In my case, about 2/3 through the >> dmesg.boot file. >=20 > Hi Kevin, it's been a while .. >=20 > Danny, can you put up a verbose boot dmesg.boot of one(?) for a = browse?=20 > Or maybe apu-4 and -1, if not all. I'd expect error msgs on -1 = anyway. they are now available at: http://www.cs.huji.ac.il/~danny/pcengines/ = >=20 >> I have p4tcc and throttling explicitly turned off (which should now = be the >> default), but my Sandy Bridge Core i5 still shows: >> dev.cpu.0.freq_levels: 2501/35000 2500/35000 2000/26426 1800/23233 >> 1600/20164 1400/17226 1200/14408 1000/11713 800/9140 >=20 > All truly available I see on more recent processors. Certainly not = 1/8=20 > duty-cycle multipliers as p4tcc and maybe? acpi_throttle (not seen = here) >=20 >> The first is really bogus to indicate "turbo" mode. >=20 > Usefully bogus, in that you can flag powerd to (in your case) -M 2500 = to=20 > prevent it engaging "turbo" mode, as I do on my old Core2Duo, as = advised=20 > by Warner years ago to avoid overheating on buildworlds and such - but=20= > more recent incarnations of "turbo" are supposedly far more = functional. >=20 > Admittedly a digression .. mostly coming from wondering about data = Karl > posted in response, indicating different Cx levels available and so = used=20 > by the latter 3 AP cores, which was news to me. I'd like to know = more,=20 > if only for gratuitous curiosity. Others can tick their TL;DR box :) >=20 >> Temperature is a totally separate issue. It is VERY sensitive to = external >> issue like airflow and position of the CPU in relation to other = components >> in the chassis Also, unless you have a lot of cores, you probably = should >> set both economy_cx_lowest and performance_cx_lowest to Cmax. Economy >> should default to that, but performance will not as that can cause = issues >> on systems with large numbers of cores, so is set to C2. Many such = system >> used to disable deeper sleep modes in BIOS, but I am way behind the = times >> and don't know about the current state of affairs. Certainly for = systems >> with 32 or fewer cores, this should not be an issue. In any case, Cx = state >> can sharply impact temperature. >=20 > Indeed. But as these are low-power devices already, it's likely less = of=20 > a concern, but maximising efficiency and minimising stress never = hurts. >=20 >> Finally, the last case with power levels of -1 for all frequencies is >> probably because the CPU manufacturer (Intel?) has not published this >> information. For a while they were treating this as "proprietary" >> information. Very annoying! It's always something that is not readily >> available. Thi is one reason I suspect your CPUs are not identical. >=20 > Hmm, bought as a batch, that sounds unlikely, though their BIOSes = (ono)=20 > may vary, and would be worth checking on each - and BIOS settings, = too. >=20 > Danny, is powerd running on all these? I doubt it would load on apu-1=20= > as it stands. =20 it is working on the apu-1! > Note these are 'pure' 1/8 factors of 1000, = p4tcc-alike,=20 > and I think quite likely indicate that cpufreq(4) failed to = initialise?=20 > debug.cpufreq.verbose=3D1 in /boot/loader.conf might show a clue, with = a=20 > verbose dmesg.boot anyway. >=20 > Later: oops, just reread Karl's message, where I was unfaniliar with=20= > different CPUs showing different C-states, and noticing that despite=20= > cpu0 showing C2(io) available, and cx_lowest as C2, yet it used 100% = C1=20 > state, which was all that was available to cpu1 to 3. >=20 > But then I twigged to Karl's hwpstate errors, so with 'apropos = hwpstate'=20 > still showing nothing after all these years, along with other = cpufreq(4)=20 > drivers, I used the list search via duckduckgo to finally find one (1)=20= > message, which lead to one detailed thread (that I even bought into!) >=20 > = https://lists.freebsd.org/pipermail/freebsd-stable/2012-May/subject.html = = > = https://lists.freebsd.org/pipermail/freebsd-stable/2012-June/thread.html = = >=20 > /hwpstate Note the May one needs following by Subject, else it splits=20= > into 5 separate threads (?) >=20 > Which may be interesting to cpufreq nerds, but had me remember that=20 > hwpstate(0) is for AMD not Intel CPUs. So now I'm totally confused :) >=20 > Danny, do your results from Karl's sysctl listings agree with his? yes, except mine seem to be running at a higher temperature. thanks, danny >=20 > cheers, Ian