Kimmo Paasiala
2015-May-23 14:40 UTC
CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, May 23, 2015 at 5:15 PM, Ian Smith <smithi at nimnet.asn.au> wrote:> On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote: > > On Sat, May 23, 2015 at 10:00 AM, Ian Smith <smithi at nimnet.asn.au> wrote: > > > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: > > > > On Fri, May 22, 2015 at 8:19 PM, Ian Smith <smithi at nimnet.asn.au> wrote: > > > > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: > > > > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko <fidaj at ukr.net> wrote: > > > [..] > > > > >> Try changing the options in /boot/device.hints > > > > >> hint.acpi_throttle.0.disabled="0" > > > > >> hint.p4tcc.0.disabled="0" > > > > > > > > > > > Thanks, those also fixed powerd(8) for me that stopped working after > > > > > > upgrading to stable/10 from releng/10.1. Why are those setting > > > > > > suddenly needed now? > > > [..] > > > > > Can you say exactly in what way powerd stopped working then? > > > > > > > > Powerd(8) complained (excerpt from dmesg -a): > > > > > > > > Starting powerd. > > > > powerd: no cpufreq(4) support -- aborting: No such file or directory > > > > /etc/rc: WARNING: failed to start powerd > > > > > > > > Putting those two settings in loader.conf and rebooting fixed the > > > > problem and powerd started working again apparently because cpufreq(4) > > > > device was available again. > > > > > > Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus > > > powerd - work for you, then it seems likely that you do not have EST > > > enabled in your BIOS. Or at least, we've seen another instance where > > > that was the case, which was fixed by enabling EST (or however your > > > particular BIOS refers to it .. AMD for example use different terms). > > > > > > What CPU is this? In what machine? > > > > > > If EST (ono) IS enabled in your BIOS, this needs further investigation. > > > > > > As is, powerd may be running, but it's doing so highly inefficiently; > > > refer to Stefan, Adrian and Kevin's responses for details. > > > It's an Intel Atom running amd64 version of FreeBSD stable/10: > > > > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1 > > r283292: Sat May 23 01:08:03 EEST 2015 > > root at firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 > > > > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10 > > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x40e31d<SSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE> > > AMD Features=0x20100800<SYSCALL,NX,LM> > > AMD Features2=0x1<LAHF> > > TSC: P-state invariant, performance statistics > > > > Powerd was working on 10.1-RELEASE but stopped working after upgrade > > to 10-STABLE and nothing was changed in BIOS settings. > > Which would be consistent with EST not being enabled in your BIOS; with > no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or > acpi_throttle and uses that, as a last resort really; with those also > disabled, no cpufreq, so no powerd. Have you checked BIOS settings to > confirm that you do have SpeedStep (however termed) properly enabled? > > Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels` > > > However, reading the other replies to this thread I get the impression > > that powerd(8) doesn't actually save energy on this platform and I'm > > better off without it? > > No, I don't think that's correct; using deeper C-states is most likely a > bigger win, but higher than needed CPU freq will still use extra power, > so run hotter. `sysctl dev.cpu` will also reveal your C-state usage. > > Reason I'm pursuing this is that this change shouldn't hurt, but it will > flush out those cases where people were only getting cpufreq due to use > of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS; > I suspect yours may be one such case :) If not, there's a bug to fix. > > cheers, IanLooking deeper into this it appears I don't have speedstep (EST) support in the CPU it being a crappy Atom D510: http://ark.intel.com/products/43098 This the full 'sysctl dev.cpu' output: % sysctl dev.cpu dev.cpu.3.cx_usage: 100.00% last 65712us dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_supported: C1/1/0 dev.cpu.3.%parent: acpi0 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%location: handle=\_PR_.P004 dev.cpu.3.%driver: cpu dev.cpu.3.%desc: ACPI CPU dev.cpu.2.cx_usage: 100.00% last 41518us dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_supported: C1/1/0 dev.cpu.2.%parent: acpi0 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%location: handle=\_PR_.P003 dev.cpu.2.%driver: cpu dev.cpu.2.%desc: ACPI CPU dev.cpu.1.cx_usage: 100.00% last 12706us dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_supported: C1/1/0 dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%location: handle=\_PR_.P002 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_usage: 100.00% last 3132us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.%parent: So I should keep those two hints in loader.conf to use p4tcc I guess? -Kimmo
Adrian Chadd
2015-May-23 15:15 UTC
CPU frequency doesn't drop below 1200MHz (like it used to)
Hm, no thermal monitoring and no speedstep. Could be dangerous/fun. What's the output of sysctl dev.cpu.0 ? -adrian On 23 May 2015 at 07:40, Kimmo Paasiala <kpaasial at gmail.com> wrote:> On Sat, May 23, 2015 at 5:15 PM, Ian Smith <smithi at nimnet.asn.au> wrote: >> On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote: >> > On Sat, May 23, 2015 at 10:00 AM, Ian Smith <smithi at nimnet.asn.au> wrote: >> > > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: >> > > > On Fri, May 22, 2015 at 8:19 PM, Ian Smith <smithi at nimnet.asn.au> wrote: >> > > > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: >> > > > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko <fidaj at ukr.net> wrote: >> > > [..] >> > > > >> Try changing the options in /boot/device.hints >> > > > >> hint.acpi_throttle.0.disabled="0" >> > > > >> hint.p4tcc.0.disabled="0" >> > > > > >> > > > > > Thanks, those also fixed powerd(8) for me that stopped working after >> > > > > > upgrading to stable/10 from releng/10.1. Why are those setting >> > > > > > suddenly needed now? >> > > [..] >> > > > > Can you say exactly in what way powerd stopped working then? >> > > > >> > > > Powerd(8) complained (excerpt from dmesg -a): >> > > > >> > > > Starting powerd. >> > > > powerd: no cpufreq(4) support -- aborting: No such file or directory >> > > > /etc/rc: WARNING: failed to start powerd >> > > > >> > > > Putting those two settings in loader.conf and rebooting fixed the >> > > > problem and powerd started working again apparently because cpufreq(4) >> > > > device was available again. >> > > >> > > Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus >> > > powerd - work for you, then it seems likely that you do not have EST >> > > enabled in your BIOS. Or at least, we've seen another instance where >> > > that was the case, which was fixed by enabling EST (or however your >> > > particular BIOS refers to it .. AMD for example use different terms). >> > > >> > > What CPU is this? In what machine? >> > > >> > > If EST (ono) IS enabled in your BIOS, this needs further investigation. >> > > >> > > As is, powerd may be running, but it's doing so highly inefficiently; >> > > refer to Stefan, Adrian and Kevin's responses for details. >> >> > It's an Intel Atom running amd64 version of FreeBSD stable/10: >> > >> > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1 >> > r283292: Sat May 23 01:08:03 EEST 2015 >> > root at firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 >> > >> > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU) >> > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10 >> > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> > Features2=0x40e31d<SSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE> >> > AMD Features=0x20100800<SYSCALL,NX,LM> >> > AMD Features2=0x1<LAHF> >> > TSC: P-state invariant, performance statistics >> > >> > Powerd was working on 10.1-RELEASE but stopped working after upgrade >> > to 10-STABLE and nothing was changed in BIOS settings. >> >> Which would be consistent with EST not being enabled in your BIOS; with >> no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or >> acpi_throttle and uses that, as a last resort really; with those also >> disabled, no cpufreq, so no powerd. Have you checked BIOS settings to >> confirm that you do have SpeedStep (however termed) properly enabled? >> >> Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels` >> >> > However, reading the other replies to this thread I get the impression >> > that powerd(8) doesn't actually save energy on this platform and I'm >> > better off without it? >> >> No, I don't think that's correct; using deeper C-states is most likely a >> bigger win, but higher than needed CPU freq will still use extra power, >> so run hotter. `sysctl dev.cpu` will also reveal your C-state usage. >> >> Reason I'm pursuing this is that this change shouldn't hurt, but it will >> flush out those cases where people were only getting cpufreq due to use >> of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS; >> I suspect yours may be one such case :) If not, there's a bug to fix. >> >> cheers, Ian > > Looking deeper into this it appears I don't have speedstep (EST) > support in the CPU it being a crappy Atom D510: > > http://ark.intel.com/products/43098 > > This the full 'sysctl dev.cpu' output: > > % sysctl dev.cpu > dev.cpu.3.cx_usage: 100.00% last 65712us > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_supported: C1/1/0 > dev.cpu.3.%parent: acpi0 > dev.cpu.3.%pnpinfo: _HID=none _UID=0 > dev.cpu.3.%location: handle=\_PR_.P004 > dev.cpu.3.%driver: cpu > dev.cpu.3.%desc: ACPI CPU > dev.cpu.2.cx_usage: 100.00% last 41518us > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_supported: C1/1/0 > dev.cpu.2.%parent: acpi0 > dev.cpu.2.%pnpinfo: _HID=none _UID=0 > dev.cpu.2.%location: handle=\_PR_.P003 > dev.cpu.2.%driver: cpu > dev.cpu.2.%desc: ACPI CPU > dev.cpu.1.cx_usage: 100.00% last 12706us > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_supported: C1/1/0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%location: handle=\_PR_.P002 > dev.cpu.1.%driver: cpu > dev.cpu.1.%desc: ACPI CPU > dev.cpu.0.cx_usage: 100.00% last 3132us > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/1/0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%location: handle=\_PR_.P001 > dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.%parent: > > So I should keep those two hints in loader.conf to use p4tcc I guess? > > -Kimmo > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
Ian Smith
2015-May-23 15:57 UTC
CPU frequency doesn't drop below 1200MHz (like it used to)
On Sat, 23 May 2015 17:40:26 +0300, Kimmo Paasiala wrote:
> On Sat, May 23, 2015 at 5:15 PM, Ian Smith <smithi at nimnet.asn.au>
wrote:
[..]
> > > It's an Intel Atom running amd64 version of FreeBSD
stable/10:
> > >
> > > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
> > > r283292: Sat May 23 01:08:03 EEST 2015
> > > root at firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64
> > >
> > > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz
K8-class CPU)
> > > Origin="GenuineIntel" Id=0x106ca Family=0x6
Model=0x1c Stepping=10
> > >
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > >
Features2=0x40e31d<SSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE>
> > > AMD Features=0x20100800<SYSCALL,NX,LM>
> > > AMD Features2=0x1<LAHF>
> > > TSC: P-state invariant, performance statistics
> > >
> > > Powerd was working on 10.1-RELEASE but stopped working after
upgrade
> > > to 10-STABLE and nothing was changed in BIOS settings.
[..]
> > > However, reading the other replies to this thread I get the
impression
> > > that powerd(8) doesn't actually save energy on this
platform and I'm
> > > better off without it?
> >
> > No, I don't think that's correct; using deeper C-states is
most likely a
> > bigger win, but higher than needed CPU freq will still use extra
power,
> > so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.
> >
> > Reason I'm pursuing this is that this change shouldn't hurt,
but it will
> > flush out those cases where people were only getting cpufreq due to
use
> > of a 'relative' cpufreq driver like p4tcc, unless EST's
enabled in BIOS;
> > I suspect yours may be one such case :) If not, there's a bug to
fix.
Seems _I've_ got a bug to fix; I need to stop assuming all modern Intel
CPUs are going to make SpeedStep and/or deeper C-states available :(
> Looking deeper into this it appears I don't have speedstep (EST)
> support in the CPU it being a crappy Atom D510:
>
> http://ark.intel.com/products/43098
Indeed. It is rated at only 13W TDP, so relatively low power anyway.
> This the full 'sysctl dev.cpu' output:
>
> % sysctl dev.cpu
> dev.cpu.3.cx_usage: 100.00% last 65712us
> dev.cpu.3.cx_lowest: C1
> dev.cpu.3.cx_supported: C1/1/0
[..]
> dev.cpu.0.cx_usage: 100.00% last 3132us
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%location: handle=\_PR_.P001
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.%parent:
It doesn't even provide dev.cpu.0.freq, and has no deeper C-states
('Idle States' on that page) available, so it looks like you may as well
not bother running powerd. Others maybe can offer better suggestions.
> So I should keep those two hints in loader.conf to use p4tcc I guess?
If this is a desktop I'd just let it run flat out, ie disable p4tcc and
acpi_throttle, have no cpufreq and forget powerd.
If it's a laptop and power consumption on battery matters to you, you
could see if p4tcc's lower frequencies actually save any power much, by
running 'powerd -v' in a terminal while testing with different loads, or
if your 'acpiconf -i0' shows discharging rates in mA or mW, or both.
Sorry again for my poor assumption, and thanks for the data point!
cheers, Ian