All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.