Date: Sat, 3 May 2014 22:53:45 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "current@freebsd.org" <current@freebsd.org>, Matthias Apitz <guru@unixarea.de>, David Chisnall <theraven@freebsd.org>, Eitan Adler <lists@eitanadler.com>, "freebsd-hackers@freebsd.org" <hackers@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, Jordan Hubbard <jkh@mail.turbofuzz.com> Subject: Re: Leaving the Desktop Market Message-ID: <CAN6yY1ukYxuf=jwBVbepCg84k54HdquyCiwpRx%2BB=SQ1hb0efg@mail.gmail.com> In-Reply-To: <CAJ-Vmo=zXyuyARapz4UCaTwMtWtW_8ys0pgssHOOUhnA-5Bt4g@mail.gmail.com> References: <CAF6rxgkeBozvfV-L0%2BrFZ6fWRn0=Gi3BNq1kPL=-HTq0TD6MkQ@mail.gmail.com> <A70900DF-4BAA-427F-8731-01211FFD1887@mail.turbofuzz.com> <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <CAJ-VmokHQvb2S-1c08J3RECUMosQ%2Bcd1gdB91LAb5famfKqP5w@mail.gmail.com> <20140503192305.GA1847@La-Habana> <CAJ-Vmon1ZYX18SN1f=z9N=hSgpZrAxXMxiJBUDWk6LYvMRiHmw@mail.gmail.com> <CAN6yY1uo08PDsYJ2KQNjw4hYuNsNJUvRu1b0cG%2B387F6Owkukg@mail.gmail.com> <536592D1.7080403@freebsd.org> <CAN6yY1tdsitXmGeu87OBw6RZ_s0qDvuoYXbTJVjnr74k6oM4Ag@mail.gmail.com> <CAJ-Vmo=zXyuyARapz4UCaTwMtWtW_8ys0pgssHOOUhnA-5Bt4g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 3, 2014 at 9:49 PM, Adrian Chadd <adrian@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@gmail.com> wrote: > > On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn <nwhitehorn@freebsd.org > > > > wrote: > >> > >> On 05/03/14 16:59, Kevin Oberman wrote: > >>> > >>> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd <adrian@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@gmail.com > -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1ukYxuf=jwBVbepCg84k54HdquyCiwpRx%2BB=SQ1hb0efg>