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 22:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48246C3E.7010608@ceibo.fiec.espol.edu.ec>
2008-05-14 0:48 ` About p4-clockmod breakage/removal 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox