From owner-cvs-src@FreeBSD.ORG Mon Aug 29 05:37:43 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D72016A41F; Mon, 29 Aug 2005 05:37:43 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A17943D53; Mon, 29 Aug 2005 05:37:42 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.250] (adsl-64-171-187-62.dsl.snfc21.pacbell.net [64.171.187.62]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7T5bfo5030681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Aug 2005 22:37:44 -0700 Message-ID: <43129EE6.7040608@root.org> Date: Sun, 28 Aug 2005 22:36:38 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <200508240752.j7O7qxep016309@repoman.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruno Ducrot , cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/powerd powerd.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 05:37:43 -0000 Hajimu UMEMOTO wrote: >>>>>>On Wed, 24 Aug 2005 20:14:42 +0900 >>>>>>Hajimu UMEMOTO said: > > ume> It feels too lazy for my laptop. One freq level for decreasing and > ume> two freq level for incresing is comfortable to me. > > Oops, I meant two and four. > Because, my main laptop has double CPU levels than my second laptop. > So, it takes double iteration for transition from highest to lowest or > from lowest to highest. Hello, I am back from vacation. As Kevin and Bruno will attest, I was not happy to go down this path since you can't make everyone happy without a proper predictive algorithm. For small numbers of levels, this algorithm works fine. For large numbers of levels, it can oscillate just as much as the previous algorithm when there is a periodic load. I do not think you should add an option to tune the parameters as this algorithm should be removed as soon as we have something better. I don't want to make it permanent by adding user-visible flags. The right fix is the project that was started by a Summer of Code participant to profile a set of predictive algorithms and choose the best. Some good background info about this is here if someone wants to take up this task: http://wikitest.freebsd.org/moin.cgi/powerd Another mitigating factor is a patch I hope to commit soon that removes levels that aren't useful. The general idea is the same as a recent email from Tijl Coosemans but my approach is different. -- Nate