From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 25 17:07:04 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A5AC106566C for ; Thu, 25 Mar 2010 17:07:04 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id CDCB48FC08 for ; Thu, 25 Mar 2010 17:07:03 +0000 (UTC) Received: (qmail 46406 invoked from network); 25 Mar 2010 16:40:22 -0000 Received: from unknown (HELO ?10.0.0.170?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 25 Mar 2010 16:40:22 -0000 Message-ID: <4BAB91D4.5030700@acm.poly.edu> Date: Thu, 25 Mar 2010 12:39:48 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100325) MIME-Version: 1.0 To: Nate Lawson References: <201003251630.o2PGU4GZ014200@freefall.freebsd.org> In-Reply-To: <201003251630.o2PGU4GZ014200@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to cpufreq X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:07:04 -0000 Nate Lawson wrote: > The following reply was made to PR kern/144232; it has been noted by GNATS. > > From: Nate Lawson > To: Dan Lukes > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to > cpufreq > Date: Thu, 25 Mar 2010 09:06:04 -0700 > > Dan Lukes wrote: > > It sound like improper place for implementation of such logic. > > > > Cpufreq is hardware driver - it allow others to control CPU speeds. It > > do no own decisions nor should do (imho). When it should not do > > decisions, then it's not appropriate place to store variables that exist > > for the purpose of such decision process only. > > > > cpufreq consumers (like powerd or acpi_thermal) are there for decision > > making so such logic and configuration variables should be there. > > > > The debug.cpufreq.lowest is here because some reported levels are not > > usable in the real, not because someone decided he don't want to use it. > > Exactly right. The "lowest" sysctl was there to prevent use of modes > that users said froze their laptop. It is not for scheduling/general > policy decisions. There is no reason for "highest" as this is a > scheduling decision. Such logic should be in powerd and such control > programs. > > -- > Nate > OK. I also have code to implement -m and -M (minimum and maximum frequency, respectively) options in powerd: http://acm.poly.edu/~spawk/powerd/ It's for 7.0-RELEASE, so I will see if it needs to be brought up to date and will file a PR. -Boris