Re: Leaving the Desktop Market

On Sat, May 3, 2014 at 9:49 PM, Adrian Chadd <adrian_at_freebsd.org> 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;
>

C-states are great and I suspect that just C-states will do about as well
as anything. I can't prove it, but I suspect using P-states with C is a
bigger win, depending on load.


> * if turboboost is available - enable that, and disable it if we
> notice the CPU runs at the higher frequency for too long;
>

I think that ACPI already limits runtime in turboboost 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.);
>

Use CPUfreq to support available P-states.I trust that the good engineers
at Intel knew what they were doing when they set them up on a given CPU.
C-states  Of course, only C-states should be used by cpufreq... not TCC or
throttling.


> * make sure the lower frequencies and tcc kick in if a thermal cutoff
> is reached;
>

I tought that this was an automatic function if not disabled by ACPI.

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

Assuming we leave throttling/TCC out of it, I don't see any reason that ANY
CPU with C-state capability should not run Cmax. I have never had any issue
withe just C-states and P-states.It only seems to be an issue when combined
with lowering thottling/TCC to low values. If the CPU gets so hot that TCC
gets down to under 25% of the lowest p-state speed, something is very, very
wrong with the hardware.


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



-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman_at_gmail.com