From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 01:43:41 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BF916A46B for ; Sun, 13 Jan 2008 01:43:41 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6DB13C44B for ; Sun, 13 Jan 2008 01:43:41 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 41214 invoked from network); 13 Jan 2008 01:43:42 -0000 Received: from ppp-71-139-9-226.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.9.226) by root.org with ESMTPA; 13 Jan 2008 01:43:42 -0000 Message-ID: <47896CCA.9020309@root.org> Date: Sat, 12 Jan 2008 17:43:38 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: Stefan Lambrev References: <200801110909.m0B99tlr097501@lurza.secnetix.de> <47873840.7050401@moneybookers.com> <47894263.6010706@root.org> <478965CC.1010609@moneybookers.com> In-Reply-To: <478965CC.1010609@moneybookers.com> X-Enigmail-Version: 0.95.5 Content-Type: multipart/mixed; boundary="------------020003050706080909070507" Cc: bruno@FreeBSD.org, freebsd-current@FreeBSD.ORG Subject: Re: powerd adaptive mode latching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jan 2008 01:43:41 -0000 This is a multi-part message in MIME format. --------------020003050706080909070507 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Stefan Lambrev wrote: > Nate Lawson wrote: >> I am not sure this patch should be committed as-is. It might be better >> centralized in the cpufreq mid-layer so that all drivers benefit instead >> of just acpi_perf. If there are frequencies that are too close to each >> other (no matter what the source driver), it might be good to eliminate >> them. >> >> I'll look into it later today. >> >> -Nate >> > I fully agree that centralized solution is better. > But at this late stage of RELENG_7_0, I'm happy with this patch, as it > solves our problem and is very simple. > If you can come with something better before 7-RELEASE, it's OK, but > otherwise I think we should have this patch in the CVS and then > RELENG_7_0 (even marked as XXX) > > The other patch actually is in powerd.c and with it doesn't matter what > is the source of the information, but I personally, more like the > acpi_perf patch :) Some of us have other jobs that have nothing to do with FreeBSD. Anyway, attached is the patch (compile tested). You should test without the acpi_perf patch to be sure it is functionally equivalent. Thanks Nate --------------020003050706080909070507 Content-Type: text/x-patch; name="cpufreq_uniq1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cpufreq_uniq1.diff" Index: kern_cpu.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_cpu.c,v retrieving revision 1.28 diff -u -r1.28 kern_cpu.c --- kern_cpu.c 30 Oct 2007 22:18:08 -0000 1.28 +++ kern_cpu.c 13 Jan 2008 01:38:24 -0000 @@ -606,6 +606,17 @@ /* Finally, output the list of levels. */ i = 0; TAILQ_FOREACH(lev, &sc->all_levels, link) { + /* + * Skip levels that are too close in frequency to the + * previous levels. Some systems report bogus duplicate + * settings (i.e., for acpi_perf). + */ + if (i > 0 && CPUFREQ_CMP(lev->total_set.freq, + levels[i - 1].total_set.freq)) { + sc->all_count--; + continue; + } + /* Skip levels that have a frequency that is too low. */ if (lev->total_set.freq < cf_lowest_freq) { sc->all_count--; --------------020003050706080909070507--