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:	Fri, 28 May 2010 18:11:22 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Florian Mickler <florian@...kler.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Paul@...p1.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

2010/5/28 Rafael J. Wysocki <rjw@...k.pl>:
> On Friday 28 May 2010, Arve Hjønnevåg wrote:
>> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@...kler.org> wrote:
>> > On Thu, 27 May 2010 20:05:39 +0200 (CEST)
>> > Thomas Gleixner <tglx@...utronix.de> wrote:
> ...
>> > To integrate this with the current way of doing things, i gathered it
>> > needs to be implemented as an idle-state that does the suspend()-call?
>> >
>>
>> I think it is better no not confuse this with idle. Since initiating
>> suspend will cause the system to become not-idle, I don't think is is
>> beneficial to initiate suspend from idle.
>
> It is, if the following two conditions hold simultaneously:
>
> (a) Doing full system suspend is ultimately going to bring you more energy
>    savings than the (presumably lowest) idle state you're currently in.
>
> (b) You anticipate that the system will stay idle for a considerably long time
>    such that it's worth suspending.
>

I still don't think this matters. If you are waiting for in interrupt
that cannot wake you up from suspend, then idle is not an indicator
that it is safe to enter suspend. I also don't think you can avoid any
user-space suspend blockers by delaying suspend until the system goes
idle since any page fault could cause it to go idle. Therefore I don't
see a benefit in delaying suspend until idle when the last suspend
blocker is released (it would only mask possible race conditions).

-- 
Arve Hjønnevåg
--
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/