From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 04:49:10 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E83C1A8; Sun, 4 May 2014 04:49:10 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (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 B60F01B8B; Sun, 4 May 2014 04:49:09 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id cm18so4737842qab.8 for ; Sat, 03 May 2014 21:49:08 -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=LhRYT83uLmXX7PyhjMQO7B3GECQrqGpXFDPyX1Gjpa4=; b=iIQfAGQ3qXiTZjitYrESxslGcSmW77eN+eQbnM7gHAuwRewZuKdibPrjiQWI+hbwmI O5O09p3YoJuhdRsi3tmmmr5nYhXqZQBU8UtcZJqTvzl+C3M2DY1zjMwQbBCI12XsK1ui 3B+zeqHf5tTygl+7b9g+6utu2J0pgsL9gyWngXV1zhQgapSnNWNzSFtSpUp3vs/tGM9a SZ5hoo4PxpWE/L8pSEGJ9+sWUlCffSyGzbRfcQmRsmTL8rcf+LQNLGzJPnMpq9YE5w39 BPg+61w6/K9NfmRwnVT1D0ItLbhlLZEDaT+8eVq90oKaX9sHSKgATlHsTPm6JDk/Fb3L DifA== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr32336970qgn.4.1399178948831; Sat, 03 May 2014 21:49:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 3 May 2014 21:49:08 -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 21:49:08 -0700 X-Google-Sender-Auth: PX-YvfUDEm3e96x4Rb0fKgaV3F0 Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 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 04:49:10 -0000 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 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