Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
> Matthew Garrett wrote:
>> p4-clockmod is entirely useless. It's high-latency and doesn't drop the
>> core voltage.
>
> Nice. Is there a good alternative for P4 machines? Is the ACPI one any
> better (assuming a semi-sane BIOS)?
It really depends on
Matthew Garrett wrote:
> p4-clockmod is entirely useless. It's high-latency and doesn't drop the
> core voltage.
Nice. Is there a good alternative for P4 machines? Is the ACPI one any
better (assuming a semi-sane BIOS)?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscri
On Sat, Dec 09, 2006 at 02:12:57AM +0100, Gabor Gombas wrote:
> On Fri, Dec 08, 2006 at 06:31:55PM -0500, Anthony DeRobertis wrote:
>
> > OTOH, it works absolutely great on AMD64 chips.
>
> Not for me:
>
> powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3200+ processors (version
> 2.00.00)
> A
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
> driver: p4-clockmod
p4-clockmod is entirely useless. It's high-latency and doesn't drop the
core voltage. Deeper C states (C3/C4) will save more power, so the only
reason to have it loaded at all is to support thermal throttling.
--
Matthew Ga
John Goerzen dijo [Fri, Dec 08, 2006 at 07:20:25PM -0600]:
> > I must just repeat what you say. Of course, I cannot say how cooler or
> > how much lower on electricity does this run, but my 3GHz P4 also
> > dropped to 375MHz. And it was painful.
> >
> > I hand-adjusted the minimum to 1GHz, but sti
On Fri, Dec 08, 2006 at 06:54:33PM -0600, Gunnar Wolf wrote:
> Anthony DeRobertis dijo [Fri, Dec 08, 2006 at 06:31:55PM -0500]:
> > > * Will cause negligible impact on system performance. ondemand seems
> > >to have the philosophy of "max system speed unless I can be shown
> > >that the s
Anthony DeRobertis dijo [Fri, Dec 08, 2006 at 06:31:55PM -0500]:
> > * Will cause negligible impact on system performance. ondemand seems
> >to have the philosophy of "max system speed unless I can be shown
> >that the system is pretty much idle"
>
> This isn't true on this machine here.
On Fri, Dec 08, 2006 at 06:31:55PM -0500, Anthony DeRobertis wrote:
> OTOH, it works absolutely great on AMD64 chips.
Not for me:
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3200+ processors (version
2.00.00)
ACPI Exception (acpi_processor-0237): AE_NOT_FOUND, Evaluating _PSS [20060707]
po
On Thu, Dec 07, 2006 at 09:36:29AM -0600, John Goerzen wrote:
>
> * Will cause negligible impact on system performance. ondemand seems
>to have the philosophy of "max system speed unless I can be shown
>that the system is pretty much idle"
This isn't true on this machine here. Enabling i
On Thu, Dec 07, 2006 at 09:36:29AM -0600, John Goerzen wrote:
> I believe that we should enable CPU frequency scaling, and the ondemand
> governer, by default in etch.
I did not follow the cpufreq issues closely, but by reading the
linux-kernel list in the last couple of months I had the impressi
#include
* John Goerzen [Thu, Dec 07 2006, 09:36:29AM]:
> Hi,
>
> I believe that we should enable CPU frequency scaling, and the ondemand
> governer, by default in etch.
Seconded. Enable it where possible, by default.
However it shold also be turned of as soon as the user tries to turn off
the
Evgeni Golov wrote:
> On Thu, 7 Dec 2006 09:36:29 -0600 John Goerzen wrote:
>
>
>> I believe that we should enable CPU frequency scaling, and the
>> ondemand governer, by default in etch.
>>
>
> s/ondemand/conservative/
>
During Len Brown's OLS talk about the ondemand governor [1], I as
On Thu, Dec 07, 2006 at 03:22:35PM -0600, John Goerzen wrote:
> On Thu, Dec 07, 2006 at 07:28:50PM +0100, Mattia Dongili wrote:
> > arch/sparc64/kernel/us2e_cpufreq.c: policy->cpuinfo.transition_latency
> > = 0;
> > arch/sparc64/kernel/us3_cpufreq.c: policy->cpuinfo.transition_latency
>
On Thu, Dec 07, 2006 at 07:28:50PM +0100, Mattia Dongili wrote:
> arch/sparc64/kernel/us2e_cpufreq.c: policy->cpuinfo.transition_latency =
> 0;
> arch/sparc64/kernel/us3_cpufreq.c: policy->cpuinfo.transition_latency =
> 0;
>
> I'd say half of the supported cpus haven't ondemand/conserva
On Thu, Dec 07, 2006 at 11:07:46AM -0600, John Goerzen wrote:
> On Thu, Dec 07, 2006 at 05:23:51PM +0100, Hendrik Sattler wrote:
[...]
> > "The support for this governor depends on CPU capability to do fast
> > frequency
> > switching (i.e, very low latency frequency transitions)."
> > The most i
On Thu, Dec 07, 2006 at 05:43:07PM +0100, Marco d'Itri wrote:
> On Dec 07, John Goerzen <[EMAIL PROTECTED]> wrote:
>
> > 1. Compile all the CPU frequency drivers (not the governors) into the
> >kernel statically. This should only add about 150K to the kernel
> >size. We don't currently h
On Thu, Dec 07, 2006 at 05:23:51PM +0100, Hendrik Sattler wrote:
> Am Donnerstag 07 Dezember 2006 16:36 schrieb John Goerzen:
> > I believe that we should enable CPU frequency scaling, and the ondemand
> > governer, by default in etch.
>
> Did you read the kernel help for it?:
So, broadly speakin
Hi,
please don't CC me ;)
On Thu, 7 Dec 2006 10:31:38 -0600 John Goerzen wrote:
> On Thu, Dec 07, 2006 at 05:03:42PM +0100, Evgeni Golov wrote:
> > On Thu, 7 Dec 2006 09:36:29 -0600 John Goerzen wrote:
> >
> > > I believe that we should enable CPU frequency scaling, and the
> > > ondemand gover
On Dec 07, John Goerzen <[EMAIL PROTECTED]> wrote:
> 1. Compile all the CPU frequency drivers (not the governors) into the
>kernel statically. This should only add about 150K to the kernel
>size. We don't currently have a way to autodetect which CPU
>frequency driver to use for a mac
Am Donnerstag 07 Dezember 2006 16:36 schrieb John Goerzen:
> I believe that we should enable CPU frequency scaling, and the ondemand
> governer, by default in etch.
Did you read the kernel help for it?:
"The support for this governor depends on CPU capability to do fast frequency
switching (i.e,
On Thu, Dec 07, 2006 at 05:03:42PM +0100, Evgeni Golov wrote:
> On Thu, 7 Dec 2006 09:36:29 -0600 John Goerzen wrote:
>
> > I believe that we should enable CPU frequency scaling, and the
> > ondemand governer, by default in etch.
>
> s/ondemand/conservative/
I personally wouldn't mind that. My
On Thu, 7 Dec 2006 09:36:29 -0600 John Goerzen wrote:
> I believe that we should enable CPU frequency scaling, and the
> ondemand governer, by default in etch.
s/ondemand/conservative/
But yes, auto-freq-scaling would be some good thing (even on servers,
my amd64 runs with 1GHz instead of 2GHz,
Hi,
I believe that we should enable CPU frequency scaling, and the ondemand
governer, by default in etch.
By doing so, we:
* Save our users money with their power bills
* Reduce the contribution to pollution and global warming by machines
running Debian, and thus help to save the planet.
23 matches
Mail list logo
