linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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:	Thu, 3 Jun 2010 13:24:06 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arve Hj?nnev?g <arve@...roid.com>,
	Paul@...p1.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Alan Stern wrote:
> > And to answer Thomas's question: The whole reason for having in-kernel 
> > suspend blockers is so that userspace can tell the system to suspend 
> > without losing wakeup events.
> > 
> > Suppose a key is pressed just as a user program writes "mem" to
> > /sys/power/state.  The keyboard driver handles the keystroke and queues
> > an input event.  Then the system suspends and doesn't wake up until
> > some other event occurs -- even though the keypress was an important
> > one and it should have prevented the system from suspending.
> > 
> > With in-kernel suspend blockers and opportunistic suspend, this 
> > scenario is prevented.  That is their raison-d'etre.
> 
> I tend to disagree. You are still looking at suspend as some extra
> esoteric mechanism. We should stop doing this and look at suspend (to
> RAM) as an additional deep idle state, which is well defined in terms
> of power savings and wakeup latency. That's what I think opportunistic
> suspend is all about. Now if you look at our current idle states in
> x86 the incoming keystroke is never lost. 
> 
For systems with runtime PM and deep idle states in cpuidle suspend is
already fairly opportunistic. If sleep states (including suspend to RAM
and CPU off) are factored in to cpuidle then it's very easy to get in to
situations where everything simply shuts off automatically, which can be
problematic if a platform doesn't expose any external wakeup sources.

Platforms still need to be able to establish some heuristics, whether
this is via blocking certain state transitions or simply defining a
maximum acceptable suspend depth irrespective of latency (at least we
presently don't have a clean interface for preventing entry in to
impossible to recover from idle states outside of latency hints via PM
QoS, or at least not one that I'm aware of).

On the other hand, while this isn't that difficult for the UP case it
does pose more problems for the SMP case. Presently the suspend paths
(suspend-to-RAM/hibernate/kexec jump) all deal with disabling and
enabling of non-boot CPUs via CPU hotplug explicitly, which will clear
them from the online CPU map. We would have to rework the semantics a bit
if cpuidle were also permitted to opportunistically offline CPUs.
--
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/