From owner-freebsd-current@FreeBSD.ORG Sun May 4 05:29:34 2014 Return-Path: Delivered-To: freebsd-current@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 45688F7D for ; Sun, 4 May 2014 05:29:34 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (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 013871FE7 for ; Sun, 4 May 2014 05:29:33 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id e16so3983537qcx.28 for ; Sat, 03 May 2014 22:29:32 -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=rgGm6+FK58zHWpdhOpHNWerbkTQTUfXiBDpwtTZo8Ls=; b=JuZBs9Y96QRt08i0hsfni4vNAYY/zMZ4xQQnrdyqZmaIOHdBUyx1WoO8d6STfwwT+k CBk/fVew3sw44Mh7b05T7/IsgPsz8P6L8sD0UUfprHimuddP0mnrGW8NTRXQ/4vG4zeZ wUGdCflq+104nnFuF98eZhmrsIgm457DIi7x+UDNnQDRn9yvpZhu32FLQ5J9tI3B4HPN wUXKVZfKPkXOCBjU9TIgiD9bepkQ9tHUm1Iv8Am1AgRCmVDYpLHNWgc9ouHUvmAnLcH9 nLkaieX4JNrPBBQdHxKNmZoaxxJXutCRiRSiC4jHy81uXRTBKfhqQ9fbBuB7a0I6Tbco oibw== MIME-Version: 1.0 X-Received: by 10.140.109.70 with SMTP id k64mr32758762qgf.92.1399181372516; Sat, 03 May 2014 22:29:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 3 May 2014 22:29:32 -0700 (PDT) In-Reply-To: <5365C78E.6030600@allanjude.com> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> <5365C78E.6030600@allanjude.com> Date: Sat, 3 May 2014 22:29:32 -0700 X-Google-Sender-Auth: SXZ-llcnveTZaMnvJupvRjAlaI0 Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Allan Jude Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 05:29:34 -0000 On 3 May 2014 21:52, Allan Jude wrote: > 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 So, there's daemons running around in SMI or silicon or something else that's doing dirty, dirty things with the target frequency per-core. It seems to monitor the core frequencies and temperatures to decide what a suitable turboboost target is. We could just leave it on and only switch it off (and go to P1 instead of P0, or whatever the nomenclature is) after some long period of time. Or drop to P1 if the cpu temperature is too hot (ie to coax it to cool down quicker.) >> * 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. I'm not sure. I think those who care / know enough just put relevant bits into /etc/rc.conf and /boot/loader.conf rather than flipping it on by default. I'm kind of tempted to just flip on Cmax by default and teach powerd to not do cpufreq unless there's a thermal issue. Then take a step back and see what happens. -a