Re: Leaving the Desktop Market

Hi,

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
frequency=Z.);
* 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
fine.

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



-a


On 3 May 2014 21:16, Kevin Oberman <rkoberman_at_gmail.com> wrote:
> 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