Re: Improved Intel Turbo Boost status/control

On Mon, 2012-03-12 at 22:52 +0200, Alexander Motin wrote:
> On 03/12/12 22:45, Ian Lepore wrote:
> > On Mon, 2012-03-12 at 21:15 +0200, Alexander Motin wrote:
> >> I'd like to note that recent r232793 change to cpufreq(4) in HEAD opened
> >> simple access to the  Intel Turbo Boost status/control. I've found that
> >> at least two of my desktop systems (based Nehalem and SandyBridge Core
> >> i7s) with enabled Intel Turbo Boost in BIOS it is not use it by default,
> >> unless powerd is enabled. And before this change it was difficult to
> >> detect/fix.
> >>
> >> ACPI reports extra performance level with frequency 1MHz above the
> >> nominal to control Intel Turbo Boost operation. It is not a bug, but
> >> feature:
> >> dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ...
> >> In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz.
> >>
> >> After boot with default settings I see:
> >> dev.cpu.0.freq: 2933
> >> , that means Turbo Boost is disabled.
> >>
> >> Enabling powerd or just adding to rc.conf
> >> performance_cpu_freq="HIGH"
> >> enables Turbo Boost and adds extra 10-20% to the system performance.
> >>
> >> Turbo Boost operation can be monitored in run-time via the PMC with
> >> command that prints number or really executed cycles per CPU core:
> >> pmcstat -s unhalted-core-cycles -w 1
> >>
> >
> > The r232793 patch applies cleanly to 8-stable and builds just fine, but
> > after install/reboot I don't see a change in the freq_levels
> >
> >          revolution>  sysctl dev.cpu.0
> >          dev.cpu.0.%desc: ACPI CPU
> >          dev.cpu.0.%driver: cpu
> >          dev.cpu.0.%location: handle=\_PR_.P001
> >          dev.cpu.0.%pnpinfo: _HID=none _UID=0
> >          dev.cpu.0.%parent: acpi0
> >          dev.cpu.0.coretemp.delta: 70
> >          dev.cpu.0.coretemp.resolution: 1
> >          dev.cpu.0.coretemp.tjmax: 101.0C
> >          dev.cpu.0.coretemp.throttle_log: 0
> >          dev.cpu.0.temperature: 31.0C
> >          dev.cpu.0.freq: 3333
> >          dev.cpu.0.freq_levels: 3333/130000 3200/117000 3067/105000
> >          2933/94000 2800/85000 2667/76000 2533/68000 2400/61000
> >          2267/54000 2133/48000 2000/43000 1867/39000 1733/35000
> >          1600/32000 1400/28000 1200/24000 1000/20000 800/16000 600/12000
> >          400/8000 200/4000
> >          dev.cpu.0.cx_supported: C1/32 C2/96 C3/128
> >          dev.cpu.0.cx_lowest: C1
> >          dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 657us
> >          revolution>
> >
> >
> > I would have expected a 3334 entry to appear after the reboot.  Is this
> > expected (like are there other required changes missing in 8-stable), or
> > do I have something misconfigured?  (I can post more info, but don't
> > want to spam the list if the answer is going to be "this shouldn't work
> > in 8.x).
> 
> I don't know any reason why it should not work on 8.x. It is ACPI BIOS 
> duty to report set of frequencies. This patch just makes system to 
> follow it more close. Make sure your CPU supports Turbo Boost and it is 
> enabled in BIOS. On my system disabling Turbo Boost in BIOS removes the 
> frequency from the list.
> 

It was indeed a bios config thing (I had it enabled, but then a side
effect of one of my overclock settings caused the bios to quietly
disable it).  I got that straightened out, and now it's working great.
Setting dev.cpu.0.freq=3334 cuts about 90 seconds off my standard
workflow-benchmark (that's 90 seconds off a 20 minute compile/build
process, a noticible improvement).

I found that setting performance_cpu_freq="HIGH" doesn't work on my
desktop system, I guess because devd never gets any AC adapter events
that trigger running the power_profile script.  I enabled it manually by
adding these lines to my /etc/sysctl.conf:

  hw.acpi.cpu.cx_lowest=C2
  dev.cpu.0.freq=3334

It would be nice to come up with a way to automatically enable this for
desktop users.  If not fully automatic, hopefully require no more than a
simple =YES knob in rc.conf.

Thanks for this work, Alexander!  I had assumed I was already getting
turbo mode benefits automatically just because my chip supports it.
It's a nice bonus to suddenly get another 7% improvement on my benchmark
when I thought I was already tweaked for max performance.

-- Ian