All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Gene Heskett <gheskett@wdtv.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	"Brown, Len" <len.brown@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Linux PM list <linux-pm@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH v2 3/6] PowerCap: Added to drivers build
Date: Mon, 07 Oct 2013 08:46:26 -0700	[thread overview]
Message-ID: <5252D752.90401@linux.intel.com> (raw)
In-Reply-To: <201310061616.00303.gheskett@wdtv.com>

On 10/6/2013 1:15 PM, Gene Heskett wrote:
>> and if you wonder what linux does today without the framework; there are
>> mechanisms that kick in at the very end of the range, that are very
>> draconian like taking the 3.0Ghz processor down to effectively 100MHz,
>> or even a system reboot. The point of what Jacob and Srinivas are trying
>> to add is to intervene slightly earlier (these failsafe mechanisms are
>> still there) but much much more gently.
>
> First off, we are not using the type of boards for controllers that would
> burn anything up sans its normal cooling, which is entirely passive on an
> atom powered board as you well know.  So there is no fan to fail and start
> your doomsday scenario in abut 30% of the cases now, but there are a rather
> dukes mixture of other boards being used yet.  Those will be replaced in
> due time as they fail, or the IRQ latency finally starts costing the shop
> owner money because the machine can't be run at the optimum speed with that
> poorly architect-ed board, probably with Atoms or BBB's.

so if your system today never hits the thermal shutdown...
... you're not going to hit anything powercapping either.



> If you insist on doing this, in the face of ample evidence its nothing but
> a feel good action on your part, then the least we ask is for a tally
> signal output, far enough in advance, say 0.25 seconds, to do a graceful,

btw one thing to note that this is just the kernel mechanism; the actual
knobs that it provides get turned by some userspace daemon..
I would fully expect that if you even ship such a daemon on your realtime device,
that you build in the notification for sure.


> In fact, I'd go so far as to say that any hardware capable of self-
> destructing in normal operation, does not need to guarded by this proposed
> function, but blacklisted instead, it is patently a defective design from
> square one regardless of the brand name on the box.  Or just let it burn
> up, the warranty returns will educate the maker/designer soon enough.

self-destruct or reboot... either case you will not like it.



  reply	other threads:[~2013-10-07 15:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04 16:36 [PATCH v2 0/6] Power Capping Framework and RAPL Driver Srinivas Pandruvada
2013-10-04 16:36 ` [PATCH v2 1/6] PowerCap: Documentation Srinivas Pandruvada
2013-10-04 16:36 ` [PATCH v2 2/6] PowerCap: Add class driver Srinivas Pandruvada
2013-10-04 16:51   ` Greg KH
2013-10-04 20:06     ` Srinivas Pandruvada
2013-10-04 16:36 ` [PATCH v2 3/6] PowerCap: Added to drivers build Srinivas Pandruvada
2013-10-04 19:24   ` Gene Heskett
2013-10-04 19:38     ` Srinivas Pandruvada
     [not found]       ` <201310041622.29259.gheskett@wdtv.com>
2013-10-04 20:55         ` Srinivas Pandruvada
2013-10-04 23:17           ` Gene Heskett
2013-10-06 15:50             ` Arjan van de Ven
2013-10-06 20:15               ` Gene Heskett
2013-10-07 15:46                 ` Arjan van de Ven [this message]
2013-10-04 16:36 ` [PATCH v2 4/6] x86/msr: add 64bit _on_cpu access functions Srinivas Pandruvada
2013-10-04 16:36 ` [PATCH v2 5/6] bitops: Introduce BIT_ULL Srinivas Pandruvada
2013-10-04 16:36 ` [PATCH v2 6/6] Introduce Intel RAPL power capping driver Srinivas Pandruvada
2013-10-04 18:07   ` Joe Perches
2013-10-04 20:12     ` Jacob Pan
2013-10-04 22:14       ` Joe Perches
2013-10-04 23:25         ` Jacob Pan

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=5252D752.90401@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=gheskett@wdtv.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=srinivas.pandruvada@linux.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.