Re: Leaving the Desktop Market

On 2014-05-04 00:49, Adrian Chadd wrote:
> 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;

If I recall correctly, the BIOS has settings that control and limit how
long the CPU will run in 'turbo boost' mode

> * 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.

According to the wiki, in 9.x and onward there is code that is supposed
to detect if the higher Cx states are usable, and not use them if they
are not, but I do not know how well this works.

> 
> 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
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 


-- 
Allan Jude