Re: Improved Intel Turbo Boost status/control

From: Ivan Klymenko <fidaj_at_ukr.net>
Date: Mon, 12 Mar 2012 22:51:35 +0200
В Mon, 12 Mar 2012 22:38:16 +0200
Alexander Motin <mav_at_FreeBSD.org> пишет:

> On 03/12/12 22:22, Ivan Klymenko wrote:
> > В Mon, 12 Mar 2012 22:11:28 +0200
> > Alexander Motin<mav_at_FreeBSD.org>  пишет:
> >
> >> On 03/12/12 22:05, Ivan Klymenko wrote:
> >>> В Mon, 12 Mar 2012 21:55:21 +0200
> >>> Alexander Motin<mav_at_FreeBSD.org>   пишет:
> >>>
> >>>> On 03/12/12 21:33, Ivan Klymenko wrote:
> >>>>> В Mon, 12 Mar 2012 21:15:35 +0200
> >>>>> Alexander Motin<mav_at_FreeBSD.org>    пишет:
> >>>>>> 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
> >>>>>>
> >>>>>
> >>>>> Thank you very much!
> >>>>> performance_cpu_freq="HIGH"
> >>>>> and as this option must be combined with state of the processor
> >>>>> C1 C2 C3?
> >>>>> performance_cx_lowest="XX"
> >>>>> economy_cx_lowest="XX"
> >>>>
> >>>> The more CPU cores on package are sleeping and the deeper they
> >>>> are sleeping, the bigger will be boost for remaining active
> >>>> cores. Without using deeper C-states boost is usually quite
> >>>> small (about 100-200MHz for desktop chips). Enabling C-states
> >>>> increases it in few times.
> >>>>
> >>>
> >>> I have a Core i5 c Turbo Boost technology (enabled in BIOS)
> >>> After the following:
> >>> sysctl dev.cpu.0.freq_levels
> >>> dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766
> >>> 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907
> >>> 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733
> >>> 200/2489 100/1244
> >>>
> >>> performance_cpu_freq="HIGH">>   /etc/rc.conf
> >>>
> >>> /etc/rc.d/powerd restart
> >>>
> >>> sysctl dev.cpu.0.freq_levels
> >>> dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766
> >>> 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907
> >>> 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733
> >>> 200/2489 100/1244
> >>>
> >>> CPU frequency does not rise above 2300 Mhz
> >>>
> >>> What am I doing wrong?
> >>
> >> performance_cpu_freq variable handled not by /etc/rc.d/powerd, but
> >> /etc/rc.d/power_profile.
> >>
> >
> > ok
> >
> > I remove and insert power supply unit connector - nothing has
> > changed...
> >
> > sysctl dev.cpu.0.freq_levels
> > dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766
> > 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907
> > 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733
> > 200/2489 100/1244
> 
> What changes do you expect to see in dev.cpu.0.freq_levels? This list
> is static. It is dev.cpu.0.freq that may change and that is where 
> difference between 2301 and 2300 should now have effect.
> 

I expected that I should be a value greater than 35000 when 2301...
it is the same as the next 2300...
Received on Mon Mar 12 2012 - 19:51:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC