Re: Leaving the Desktop Market

On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn <nwhitehorn_at_freebsd.org>wrote:

> On 05/03/14 16:59, Kevin Oberman wrote:
>
>> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd <adrian_at_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: rkoberman_at_gmail.com