Date: Thu, 08 Sep 2005 18:11:53 -0700 From: Nate Lawson <nate@root.org> To: Kevin Oberman <oberman@es.net> Cc: acpi@FreeBSD.org, Hajimu UMEMOTO <ume@FreeBSD.org>, Bruno Ducrot <bruno@poupinou.org> Subject: Re: cvs commit: src/usr.sbin/powerd powerd.c Message-ID: <4320E159.9040902@root.org> In-Reply-To: <20050830230518.F07EC5D07@ptavv.es.net> References: <20050830230518.F07EC5D07@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote: > 1. CPU idle - No measurable difference detected to this point by TCC. I > think there is a small difference, but it's going to be hard to measure. This is likely because the CPU idle spends most of its time in C3 (clocks stopped) which is always better than a partial duty cycle stopped. > 2. CPU at a constant, moderate load (mp3 playback) - TCC is > detrimental. You use less (often much less) power at an unthrottled clock > speed with the system at 10 or 20% CPU than when TCC is used and the > system is running throttled, but at 70 or 80% CPU. Yes, you want to run as fast as possible to do the computation and then go into idle (C3). > 3. CPU compute bound - TCC can reduce power consumption (at a rather > steep cost in performance. This is not generally useful EXCEPT when > needing keep the system running on battery for an extended time while CPU > bound (e.g. buildworld and building openoffice.org). Here you can keep > the battery alive for a much longer time by use of TCC than without. I > use this when building openoffice.org since my laptop needs to move from > work-location to work-location to home in the course of most builds. > > I'm limited to testing on a single platform with ICHSS and TCC. I hope > to get the tests into scripts that others can run on different platforms > (e.g. EST and AMD) to get more comprehensive results, but that will take > a bit of time. I have only the CPU bound script written at this time, > though the idle case is pretty trivial. The loading by different common > applications is a bit bigger job. As a result, I am uncomfortable > generalizing any results beyond the P4-M case. Given this, I hope you can appreciate that I am trying to anticipate future developments in this area and don't want to hobble the cpufreq arch just to satisfy current limitations. When I first started writing it, there was only ichss (2 speeds) and chipset stop-grant throttling. There may be developments in future relative technologies that will be more useful than the current ones. With the current code, you can just set a value of the lowest frequency you want used to limit the derived (p4tcc) frequencies that go down to 75 mhz. > Those qualifications stated, I'm starting to think that, pending the > completion of testing and implementation predictive power management, it's > best to use only the two "native" CPU speeds on my system and skip any > of the TCC based speeds except when doing something very CPU > intensive. > > It's going to take a lot of tweaking with a lot of knobs to really > optimize things. Sort of like converging an old color TV. If I only had > a bit more time to try things...Sigh. I've committed code that does the same things as Tijl's patch. I assume that coupled with the sysctl for lowest freq should be sufficient? -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4320E159.9040902>