From owner-freebsd-stable@FreeBSD.ORG Wed Nov 30 20:23:55 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EB5616A41F; Wed, 30 Nov 2005 20:23:55 +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 A204A43D5D; Wed, 30 Nov 2005 20:23:54 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jAUKO6ZM020261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Nov 2005 12:24:07 -0800 Message-ID: <438E0A58.60609@root.org> Date: Wed, 30 Nov 2005 12:23:52 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruno Ducrot References: <20051130133224.GA4713@poupinou.org> <438DE9D0.6080107@root.org> <20051130201250.GC4713@poupinou.org> In-Reply-To: <20051130201250.GC4713@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org, Marco Calviani , freebsd-questions@freebsd.org Subject: Re: cpufreq and changing driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 20:23:55 -0000 Bruno Ducrot wrote: > On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote: > >>Marco Calviani wrote: >> >>>Hi, >>> >>>2005/11/30, Bruno Ducrot : >>> >>> >>>>You have to load the cpufreq.ko module at boot. >>>>Adding that line: >>>>cpufreq_load = "YES" >>>>to /boot/loader.conf >>>>should be OK. >>> >>> >>>I have that line in that position, and it seems working. The point is >>>that i would like to change the driver and use (AFAIU) a better driver >>>for my system (est). >>>In particular i have: >>> >>>dev.cpu.0.%desc: ACPI CPU >>>dev.cpu.0.%driver: cpu >>>dev.cpu.0.%location: handle=\_PR_.CPU0 >>>dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>dev.cpu.0.%parent: acpi0 >>> >>>Maybe i didn't understood well: but what i have to do to use the Intel >>>Enhanced SpeedStep driver? >> >>You should send the full output of "sysctl dev.cpu". There is no >>cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look >>at your dmesg to see if one is probing/attaching. >> >>If you are using acpi and load cpufreq.ko, you've got all the cpufreq >>drivers in one package. The right one for your platform will >>automatically probe/attach. >> >> >>>>powerd need some rework in order to get it working properly. There >>>>is one FreeBSD project on that subject if you are interrested. >>> >>>Well, thanks i'm very interested, although i'm not at all experienced >>>in kernel programming.... >>> >>>I'm not inside this issue, but it would not be possible to "emulate" >>>the behaviour of the ondemand governor? (sorry if this question makes >>>no sense) >> >>I have no idea what you mean by "on-demand governor". The only >>automated control of cpu speed is either by the BIOS (which we can't >>control) or the TM/TM2 (and that one is heat-based, not load-based). >> > > > The ondemand governor is basically an implemation of the following > algorithm: > > There is a counter, say count. > > at each given fixed intervall: > if (idle less than a watermark) { > frequency full > reinitialise count to 10 > } else if (idle more than another watermark) { > decrement count > if count is 0 { > down one step the frequency > } > else reinitilize count to 10 > > > Note that in the latter case, the down step is performed only > after 10 such comparison. In other word, intervall is ten times > larger for the down side than the full frequency one. > > This work well when you can perform, say, 20 to 50 transitions per > second. Otherwise, it is pretty bad. > Send me a URL to the datasheet that says Intel implemented this. That algorithm is basically what powerd does. So just run powerd. -- Nate