linux-kernel - Re: [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations

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]

Message-ID: <alpine.DEB.2.02.1311201814410.30673@ionos.tec.linutronix.de>
Date:	Wed, 20 Nov 2013 18:23:00 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arjan van de Ven <arjan@...ux.intel.com>
cc:	Peter Zijlstra <peterz@...radead.org>, lenb@...nel.org,
	rjw@...ysocki.net, Eliezer Tamir <eliezer.tamir@...ux.intel.com>,
	Chris Leech <christopher.leech@...el.com>,
	David Miller <davem@...emloft.net>, rui.zhang@...el.com,
	jacob.jun.pan@...ux.intel.com,
	Mike Galbraith <bitbucket@...ine.de>,
	Ingo Molnar <mingo@...nel.org>, hpa@...or.com,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 3/7] idle, thermal, acpi: Remove home grown idle
 implementations

On Wed, 20 Nov 2013, Arjan van de Ven wrote:

> On 11/20/2013 8:04 AM, Peter Zijlstra wrote:
> > This does not fully preseve existing behaviour in that the generic
> > idle cycle function calls into the normal cpuidle governed idle
> > routines and should thus respect things like QoS parameters and the
> > like.
> 
> 
> NAK on the powerclamp side.
> 
> powerclamp MUST NOT do that....
> it is needed to go to the deepest state no matter what
> (this is for when your system is overheating. there is not a lot of choice
> here... alternative is an emergency reset that the hardware does for safety)

So that whole machinery falls apart when the thing which is running on
that hot core is a while(1) loop with a higher or equal FIFO priority
than this thread. Even if you'd run at prio 99, then there is no
guarantee that the cpu hog does not run with prio 99 as well and due
to FIFO and being on the CPU it's not going to let you on.

And even if the issue was caused by a lower prio CPU hog, the system
might just be in a RT throttled state because of the hog. So depending
on the throttler settings it might take quite some time for the
clamper thread to get on the CPU.

Amazingly naive and stupid approach.

Thanks,

	tglx
--
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/