From: Ducrot Bruno <ducrot@poupinou.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: acpi-devel@lists.sourceforge.net, cpufreq@www.linux.org.uk
Subject: Re: [ACPI] Re: [PATCH 2.6] update passive cooling algorithm
Date: Thu, 15 Jan 2004 14:42:29 +0100 [thread overview]
Message-ID: <20040115134229.GT14031@poupinou.org> (raw)
In-Reply-To: <20040115121833.GB12963@elf.ucw.cz>
On Thu, Jan 15, 2004 at 01:18:33PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > [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'?
>
> Of course.
>
> If you eat less power, you create less heat. CPU is basically fancy
> "turn-electricity-into-heat" device.
>
I don't like certitudes (I was wondering if better heat dissipation in
case of throttling even if more heat generation, but that not the case).
> [Have you seen that "first use of PentiumPro in house appliances"
> picture?]
No, but I do have seen some that have burnt in a production server,
some years ago...
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
next prev parent reply other threads:[~2004-01-15 13:42 UTC|newest]
Thread overview: 11+ 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
2004-01-13 8:40 ` Dominik Brodowski
2004-01-15 12:18 ` [ACPI] " Pavel Machek
2004-01-15 13:42 ` Ducrot Bruno [this message]
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
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=20040115134229.GT14031@poupinou.org \
--to=ducrot@poupinou.org \
--cc=acpi-devel@lists.sourceforge.net \
--cc=cpufreq@www.linux.org.uk \
--cc=pavel@ucw.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.