From: Ducrot Bruno <ducrot@poupinou.org>
To: len.brown@intel.com, acpi-devel@lists.sourceforge.net,
cpufreq@www.linux.org.uk
Subject: Re: [PATCH 2.6] update passive cooling algorithm
Date: Mon, 12 Jan 2004 20:11:22 +0100 [thread overview]
Message-ID: <20040112191122.GK14031@poupinou.org> (raw)
In-Reply-To: <20040112173922.GA6154@dominikbrodowski.de>
On Mon, Jan 12, 2004 at 06:39:22PM +0100, Dominik Brodowski wrote:
> On Mon, Jan 12, 2004 at 04:46:11PM +0100, Ducrot Bruno wrote:
> > On Sun, Jan 11, 2004 at 10:12:55PM +0100, Dominik Brodowski wrote:
> > > [Len, could you test and verify this patch, and push it to Linus, please?]
> > >
> > > The current algorithm used by Linux ACPI for passive thermal management has
> > > two shortcomings:
> >
> > ...
> >
> > > +/* If a passive cooling situation is detected, primarily CPUfreq is used, as it
> > > + * offers (in most cases) voltage scaling in addition to frequency scaling, and
> > > + * thus a cubic (instead of linear) reduction of energy. Also, we allow for
> > > + * _any_ cpufreq driver and not only the acpi-cpufreq driver.
> > > + */
> >
> > Just a stupid question:
> >
> > What is best if processor heat issues (apart turning on the fan)?
> >
> > Reducing voltage of the processor, but still allowing it to run execution
> > at 100% (which is the case if the processor is heating), or reduce
> > amount of time allowed for the processor to execute?
>
> voltage scaling. It offers a much better (quadratic) saving than clock
> modulation (linear saving). Doing both [and you need to do it, as the CPU
> won't run with fewer volts at the same frequency] gives you cubic savings.
Yes I know. But does it offer more 'cooling'?
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
next prev parent reply other threads:[~2004-01-12 19:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-11 21:12 [PATCH 2.6] update passive cooling algorithm Dominik Brodowski
2004-01-12 15:46 ` Ducrot Bruno
2004-01-12 17:39 ` Dominik Brodowski
2004-01-12 19:11 ` Ducrot Bruno [this message]
2004-01-13 8:40 ` Dominik Brodowski
2004-01-15 12:18 ` [ACPI] " Pavel Machek
2004-01-15 13:42 ` Ducrot Bruno
2004-01-15 22:34 ` Pavel Machek
[not found] ` <20040115223425.GC18488-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
2004-01-16 1:14 ` Micha Feigin
2004-01-16 11:24 ` [ACPI] " Ducrot Bruno
2004-01-28 22:43 ` Len Brown
-- strict thread matches above, loose matches on Subject: below --
2004-01-13 9:20 Dominik Brodowski
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=20040112191122.GK14031@poupinou.org \
--to=ducrot@poupinou.org \
--cc=acpi-devel@lists.sourceforge.net \
--cc=cpufreq@www.linux.org.uk \
--cc=len.brown@intel.com \
/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.