From: Len Brown <lenb@kernel.org>
To: Pavel Troller <patrol@sinus.cz>
Cc: "Matthew Garrett" <mjg59@srcf.ucam.org>,
cpufreq@lists.linux.org.uk,
"Alex Villacís Lasso" <avillaci@ceibo.fiec.espol.edu.ec>,
linux-acpi@vger.kernel.org
Subject: Re: About p4-clockmod breakage/removal
Date: Wed, 14 May 2008 13:22:26 -0400 [thread overview]
Message-ID: <200805141322.26879.lenb@kernel.org> (raw)
In-Reply-To: <20080514111817.GA21186@tangens.sinus.cz>
On Wednesday 14 May 2008, Pavel Troller wrote:
> > On Tue, May 13, 2008 at 08:48:00PM -0400, Len Brown wrote:
> >
> > > Assuming this is a laptop with a batter,
> > > I'd certainly be interested if you could run BLTK
> > > and measure any benefit to p4-clockmod (I've never
> > > been able to)
> >
> > The most plausible benefit to p4-clockmod is its utility in throttling
> > the CPU if it would otherwise cause the system to overheat. From that
> > point of view, I think it's worth keeping around - especially since not
> > all machines expose T states via ACPI.
> >
> Hi!
> I heavily used p4-clockmod having old, broken battery. Using it and
> throttling the CPU frequency immediately after AC disconnection was
> necessary to limit the maximum current the CPU was able to drain from
> the battery. Otherwise, the battery voltage would drop below the allowed
> level and the machine would either switch off or crash. Yes, in idle state,
> there was no change in the CPU power consumption, but during heavy CPU
> load, 75% throttle really limited the power consumption to the level
> allowing operation even with that old poor battery.
> So, p4-clockmod REALLY helped me a lot in this case. I vote for keeping
> it on its place!
> With regards, Pavel Troller
Yes, we could design Linux to be optimal for this broken hardware.
But the cost is that others with actual working hardware
unnwittingly run p4-clockmod and slow down their machine with
no energy savings benefit.
Perhaps there is a different workaround (besides purchasing
a battery or running on AC) that will help you?
Does this machine export /proc/acpi/processor/*/throttling?
-Len
next prev parent reply other threads:[~2008-05-14 17:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-09 15:22 About p4-clockmod breakage/removal Alex Villacís Lasso
2008-05-14 0:48 ` Len Brown
2008-05-14 0:56 ` Matthew Garrett
2008-05-14 3:35 ` Len Brown
2008-05-14 9:15 ` Matthew Garrett
2008-05-14 15:18 ` Len Brown
2008-05-14 23:11 ` Matthew Garrett
2008-05-14 11:18 ` Pavel Troller
2008-05-14 17:22 ` Len Brown [this message]
2008-05-15 1:55 ` Henrique de Moraes Holschuh
2008-05-15 15:06 ` Alex Villacís Lasso
2008-05-14 11:36 ` Thomas Renninger
2008-05-14 11:42 ` Matthew Garrett
2008-05-14 12:49 ` Thomas Renninger
2008-05-14 12:56 ` Matthew Garrett
2008-05-14 15:28 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200805141322.26879.lenb@kernel.org \
--to=lenb@kernel.org \
--cc=avillaci@ceibo.fiec.espol.edu.ec \
--cc=cpufreq@lists.linux.org.uk \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=patrol@sinus.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.