lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 06 Oct 2013 08:50:10 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Gene Heskett <gheskett@...v.com>
CC:	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	"Brown, Len" <len.brown@...el.com>,
	Jacob Pan <jacob.jun.pan@...ux.intel.com>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCH v2 3/6] PowerCap: Added to drivers build

On 10/4/2013 4:17 PM, Gene Heskett wrote:
>>> I hope this is a better explanation. :)
>>
>> The idea of power capping is to cap total power not power down and also
>> need root level access to modify.
>
> No.  Restricting it to root control only is NOT an option.  There has to be
> some mechanism whereby the users non-root program can control it.  We don't
> run this software as root, ever.  And the part of this software that needs
> the parport (or a pci card access) is running on a cpu core that has been
> isolated for its use by an isocpus= statement, not visible to top or any
> other system monitoring utility, so you would never know we are pounding on
> that port, both reads and multiple writes, at least 3 times every 23
> microseconds.  So you might see it as idle and turn it off.

I understand that you do not want to see powercapping in effect.
I think I mostly understand the realtime angle you're coming from as well.

However, powercapping is not done for energy savings, it is done for SURVIVAL.
It is not something optional that you can just turn off and ignore;
if you ignore it... something either has a thermal meltdown or trips a circuit breaker... or
in the case of a laptop/tablet kind of shape, you give the user burn blisters.

(the thermal meltdown effect can be either damage to the system or a hard reset done by a hardware safety
mechanism.. neither is what you want for your realtime workload)

The solution to not use powercapping in combination with realtime is to make sure there
is ample cooling for the system, and to make sure the circuit breakers are big enough...
.... not ways to try to turn it off from non-root.

(and note that powerclamp for example takes realtime priority into account by only running at "half priority"...
... but if the real realtime prevents clamping altogether, other, more dracionian things will kick in)


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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ