From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 05:53:46 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B98C139D; Sun, 4 May 2014 05:53:46 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F5E011D4; Sun, 4 May 2014 05:53:46 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id ld10so2435938pab.17 for ; Sat, 03 May 2014 22:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MUO9kitxngCcL6TShegjyukbX4Z6FcSBbEdxoxstohc=; b=Ir9wgNpWRYJfS0fPovqPgH3OfbYIyp5DKzi528IOsukhkh9zwJksZUv9Doj+4rcguE wazyuQfZXI1BkfnSoSjwg1DWj0rtsmrsXlSoAia8GzLPFGPdMRwwT5QFYGMOI4X8ovnk 6ADP3OJZlVBoFBqpM83KLTkqLpEjN8N3J9xGm04yVfgjb8UtdHxOKJhcK1v8CwmkZjn/ mC92HrzwPWOyNtvD6w1KuHDrJkddOIRJ6SEJZoyWe4cKsKZLBJz0GtVahJMsuQ+OkPyj VjJsytnHPmfvqzDJLzHdFpMWSrOLuzKINz692WO8Zp1/AfMS44UEvDSwMTVeJlvJ+eQH wXdA== MIME-Version: 1.0 X-Received: by 10.66.124.137 with SMTP id mi9mr55888968pab.111.1399182825628; Sat, 03 May 2014 22:53:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Sat, 3 May 2014 22:53:45 -0700 (PDT) In-Reply-To: References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Date: Sat, 3 May 2014 22:53:45 -0700 X-Google-Sender-Auth: RTNYB7AOY0HCCDXT-3xLfsYRLBo Message-ID: Subject: Re: Leaving the Desktop Market From: Kevin Oberman To: Adrian Chadd X-Mailman-Approved-At: Sun, 04 May 2014 11:24:31 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "current@freebsd.org" , Matthias Apitz , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Nathan Whitehorn , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 05:53:46 -0000 On Sat, May 3, 2014 at 9:49 PM, 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; > 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 wrote: > > On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn > > > wrote: > >> > >> On 05/03/14 16:59, Kevin Oberman wrote: > >>> > >>> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd > 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