From owner-freebsd-stable@FreeBSD.ORG Mon Aug 1 22:22:16 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 706F716A41F for ; Mon, 1 Aug 2005 22:22:16 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx012.isp.belgacom.be (outmx012.isp.belgacom.be [195.238.3.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3909F43D4C for ; Mon, 1 Aug 2005 22:22:13 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx012.isp.belgacom.be (localhost [127.0.0.1]) by outmx012.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j71MMAWF014925 for ; Tue, 2 Aug 2005 00:22:10 +0200 (envelope-from ) Received: from kalimero.kotnet.org (139-30.245.81.adsl.skynet.be [81.245.30.139]) by outmx012.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j71MM5ip014887; Tue, 2 Aug 2005 00:22:05 +0200 (envelope-from ) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.3/8.13.3) with ESMTP id j71MM301001106; Tue, 2 Aug 2005 00:22:03 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-stable@freebsd.org Date: Tue, 2 Aug 2005 00:22:02 +0200 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_KCq7CL3UPIm6kvw" Message-Id: <200508020022.02992.tijl@ulyssis.org> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: nate@root.org Subject: 5-STABLE cpufreq hotter than est from ports 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: Mon, 01 Aug 2005 22:22:16 -0000 --Boundary-00=_KCq7CL3UPIm6kvw Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline A couple days ago I updated my system and was excited to see cpufreq and powerd in 5-stable. Since then however I noticed that my laptop temperature is about 5=B0C higher than with est and estctrl. I found that cpufreq when setting 200MHz for example set the absolute frequency to 1600MHz (max for this laptop) and the relative frequency (p4tcc) to 12.5% instead of using a more power conserving setting like 800MHz/25%. The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) traverses freq levels from high to low when adding relative levels and skips duplicates. When it wants to add 800MHz/25% it sees this setting as a duplicate of 1600MHz/12.5% it has found before. This can be fixed by letting cpufreq_expand_set() traverse freq levels in reverse order (and still skipping duplicates). Then each frequency level has the lowest possible absolute setting. This is a one line change in sys/kern/kern_cpu.c (line 653). =2D-- sys/kern/kern_cpu.c.orig Mon Aug 1 14:42:26 2005 +++ sys/kern/kern_cpu.c Mon Aug 1 15:17:55 2005 @@ -650,7 +650,7 @@ CF_MTX_ASSERT(&sc->lock); =2D TAILQ_FOREACH(search, &sc->all_levels, link) { + TAILQ_FOREACH_REVERSE(search, &sc->all_levels, cf_level_lst, link) { /* Skip this level if we've already modified it. */ for (i =3D 0; i < search->rel_count; i++) { if (search->rel_set[i].dev =3D=3D set_arr->sets[0].= dev) With this patch temperature is almost as low as with est again (only 1=B0C hotter). However, there are still such levels like 1400/12.5 (175MHz) which are lower than let's say 600/37.5 (225MHz), but consume a lot more power. On my laptop this problem doesn't really occur because of the way powerd works, only the absolute levels 1600, 800 and 600 are ever used. I can imagine somebody with a 1700MHz cpu not being so lucky though. So, I've worked out a patch (attached) that makes sure that a lower frequency level has at most the same absolute setting (preferably less of course). This eliminates quite a few levels so somebody with a better knowledge of cpufreq should check if this patch really does something good. This is the first time I've taken a look at =46reeBSD source code by the way. Also, somewhat related, the p4tcc driver doesn't recognise acpi_throttle, which means that when you load the cpufreq module after booting, the freq levels are messed up. I'm not sure what the best solution for this is. Let p4tcc detect acpi_throttle and don't attach if it's present (like acpi_throttle does now if it finds p4tcc) or detach it before attaching? Or maybe p4tcc and acpi_throttle should be merged into one driver? =46inally, is the kernel config option CPU_ENABLE_TCC still relevant? Because it's still listed in NOTES. --Boundary-00=_KCq7CL3UPIm6kvw--