From: Frans Pop <elendil@planet.nl>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/6] thermal: add sanity check for the passive attribute
Date: Mon, 31 Aug 2009 12:30:30 +0200 [thread overview]
Message-ID: <200908311230.32021.elendil@planet.nl> (raw)
In-Reply-To: <1251707630.3483.181.camel@rzhang-dt>
On Monday 31 August 2009, Zhang Rui wrote:
> On Thu, 2009-08-27 at 00:48 +0800, Frans Pop wrote:
> > On Wednesday 26 August 2009, Matthew Garrett wrote:
> > > On Wed, Aug 26, 2009 at 06:17:23PM +0200, Frans Pop wrote:
> > > > Values below 40000 milli-celsius (limit is somewhat arbitrary)
> > > > don't make sense and can cause the system to go into a thermal
> > > > heart attack: the actual temperature will always be lower and
> > > > thus the system will be throttled down to its lowest setting.
> > >
> > > Not keen on this - it's a pretty arbitrary cutoff, and there are
> > > some cases where someone might want this value. Policy belongs in
> > > userspace, and all that.
> >
> > What cases do you see? Testing? Or systems that might have to operate
> > at such a low temperature? I deliberately chose a value that's at a
> > level that's easy to reach.
> >
> > I agree it is arbitrary, but it will prevent major confusion when
> > someone like me echo's 95 directly in sysfs.
>
> this is a problem.
> how about something like:
> #define THERMAL_PASSIVE_WARNING_LEVEL 0x40000
Hmmm. 40000 hexadecimal? That seems a bit high ;-)
> if (state < THERMAL_PASSIVE_WARNING_LEVEL)
> printk(KERN_WARNING PREFIX "Passive trip point too low, this may"
> "slow down your laptop because processors are throttled "
> "whenever the temperature is higher than %dC\n", state/1000);
Disadvantage is that users are unlikely to actually see that message at
the time they set the value, especially if they're working in some xterm.
They'd have to check dmesg or log files. It also increases the .text size
of the module for an option that very few people are likely to use.
> > Would 1000 (1 °C) perhaps be more acceptable as a limit? I doubt
> > there are valid use-cases for below 0 temps :-)
I'd prefer this option. Do you see any downside to this?
Cheers,
FJP
next prev parent reply other threads:[~2009-08-31 10:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 16:17 [PATCH 0/6] thermal: improvements re. forced passive cooling Frans Pop
2009-08-26 16:17 ` [PATCH 1/6] thermal: sysfs-api.txt - reformat for improved readability Frans Pop
2009-08-26 16:17 ` [PATCH 2/6] thermal: sysfs-api.txt - document passive attribute for thermal zones Frans Pop
2009-08-31 8:18 ` Zhang Rui
2009-08-31 11:19 ` Frans Pop
2009-09-01 0:44 ` Zhang Rui
2009-09-02 20:02 ` Pavel Machek
2009-09-03 14:34 ` Frans Pop
2009-08-26 16:17 ` [PATCH 3/6] acpi: thermal: display forced passive trip points in proc Frans Pop
2009-08-31 8:20 ` Zhang Rui
2009-08-26 16:17 ` [PATCH 4/6] thermal: add sanity check for the passive attribute Frans Pop
2009-08-26 16:23 ` Matthew Garrett
2009-08-26 16:48 ` Frans Pop
2009-08-31 8:33 ` Zhang Rui
2009-08-31 10:30 ` Frans Pop [this message]
2009-09-03 6:10 ` Zhang Rui
2009-09-03 14:33 ` [PATCH 4/6,v2] " Frans Pop
2009-08-26 16:17 ` [PATCH 5/6] thermal: Only set passive_delay for forced passive cooling Frans Pop
2009-08-26 16:25 ` Matthew Garrett
2009-09-10 16:07 ` Frans Pop
2009-09-10 16:15 ` Matthew Garrett
2009-08-26 16:17 ` [PATCH 6/6] thermal: disable polling if passive_delay and polling_delay are both unset Frans Pop
2009-08-26 16:25 ` Matthew Garrett
-- strict thread matches above, loose matches on Subject: below --
2009-10-26 7:38 [PATCH 0/6] [resend] thermal: improvements re. forced passive cooling Frans Pop
2009-10-26 7:39 ` [PATCH 4/6] thermal: add sanity check for the passive attribute Frans Pop
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=200908311230.32021.elendil@planet.nl \
--to=elendil@planet.nl \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rui.zhang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox