Well, hardware got better. A lot better. I'm happy to leave speedstep
and throttling in there but teach powerd about using C-states and
limited frequency stepping if it's available.

So, how about something like this:

* if C states are available - let's just use C states and not step the
cpu frequency at all;
* if turboboost is available - enable that, and disable it if we
notice the CPU runs at the higher frequency for too long;
* use cpufreq with some heuristics (like say, only step down to 2/3rd
the frequency if idle) - and document why that decision is made (eg on
CPU X, measuring Y at idle, power consumption was minimal at
* make sure the lower frequencies and tcc kick in if a thermal cutoff
is reached;
* default to using lower Cx states out of the box if they're decided
to not be buggy. There are a few CPUs for which lower C states cause
problems but modernish hardware (say, nehalem and later) should be

That's vaguely what I've been tossing around in my head.


On 3 May 2014 21:16, Kevin Oberman <rkober...@gmail.com> wrote:
> On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn <nwhiteh...@freebsd.org>
> wrote:
>> On 05/03/14 16:59, Kevin Oberman wrote:
>>> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd <adr...@freebsd.org> wrote:
>>>> Set it to the lowest available Cx state that you see in dev.cpu.0 .
>>> Available is not required. Set it to C8. That guarantees that you will
>>> use
>>> the lowest available. The correct incantation in rc.conf is "Cmax".
>>> performance_cx_lowest="Cmax"
>>> economy_cx_lowest="Cmax"
>>> But, unless you want laggy performance, you will probably also want:
>>> hint.p4tcc.0.disabled=1
>>> hint.acpi_throttle.0.disabled=1
>>> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix
>>> well and TCC is not effective, as mentioned earlier in this thread.
>> Is there any reason that TCC is on by default, actually? It seems like an
>> anti-feature.
> I've been baffled by this for years. Throttling was first. SpeedStep was
> about all that was available for power management and even that was not
> available for older laptops. It was thought that throttling was a way to get
> some power management for those older systems. Nate was developing the first
> power management for FreeBSD and the first implementation of SST. He threw
> in throttling as both an added capability an something for older laptops
> that lacked SpeedStep.
> It made sense to me, too, After all, SST only provided two performance
> levels. It was an improvement from nothing, but not a really a lot and,
> mostly because neither of us thought about it enough, we really believed
> throttling was a help. Before cpufreq was committed, the Pentium 4 came out,
> including TCC which did what throttling did,but much more cleanly.So cpufreq
> was modified to use TCC if available and throttling when not. In retrospect,
> this was pretty dumb, but it made sense at the time.
> Soon after that, EST (true P-states) came out. It really reduced power
> consumption in normal applications. A driver for it was added fairly
> quickly, but throttling/TCC remained. Its only real effect was to add
> several many more "frequencies" to powerd, taking longer to save power when
> the CPU was lightly loaded and causing lag in speeding up when things got
> busy.
> Next, along came C-states and, almost simultaneously, D-states. Dx was very
> closely linked to the hardware and savings were often limited, but C-states
> were the real deal. This was a huge change as it really did save power.
> Unfortunately people started reporting that Cx states were causing CPU
> lockup and very laggy interactive behavior.  As a result, the default
> setting for Cx states was to disable them. This was a really bad choice. It
> was made without any analysis of why.Cx was hanging systems and working
> badly, so turn it off.
> It took me very little time to discover the problem.My old laptop at the
> time this happened as a Pentium-M with a lowest P-state of 800 MHz. Ass TCC
> and the idle clock was effectively just 100 MHz. When you combine the way
> powerd adjusted speed and C-states, the best you can hope for is crappy
> interactivity. It just took way too long to get out of the lowest idle
> state. I can't explain the hangs as I never experienced them, but simply
> turning off TCC (and throttling) prevented it.
> It looked like the obvious thing to do was to turn off TCC and make full use
> of C-states. This became even more blindingly obvious when mav put up his
> very excellent paper on power management on FreeBSD.  If you care about
> power management and have not read it, do so now!
> https://wiki.freebsd.org/TuningPowerConsumption
> Why mav's suggestions were not made default,I simply don't understand. I'm
> sure much of it is that FreeBSD is developed primarily for servers and
> people seem to often not care much about power savings on servers, though
> this is finally changing.
> I think I got most of the history correct, though it goes back to v4, a lot
> of years ago. Since I retired, I no longer have access to my old mail, so I
> may have gotten some details wrong. If so, I apologize.
> --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to