linux-kernel - Re: [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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 May 2010 03:40:01 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Kevin Hilman <khilman@...prootsystems.com>,
	felipe.balbi@...ia.com,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 8)

On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
>
>> and on systems where the
>> same power state can be used from idle and suspend, we use suspend so
>> we can stay in the low power state for minutes to hours instead of
>> milliseconds to seconds.
>
> So don't you think working on making it possible for systems to be idle
> _that_ long would improve things for everybody? as opposed to this
> auto-suspend which only improves matters for those that (can) use it?

As we've stated a number of times in the several weeks of discussion
(this time around) of this patchset, we are all in favor of improving
runtime pm, finding and resolving issues that prevent idle, and
heading toward ever lower power states in idle -- after all, this
benefits our battery life in the cases when the system is not
suspended as well as moving us closer to a future where the power
savings between actively entering suspend and not doing so approach
zero.  Aggressively entering the lowest possible power state at all
times is our goal here.

At the moment, the power savings from opportunistic suspend do
directly lead to improved battery life, and there are some advantages
to this model in the face of a non-optimal userspace (as we encounter
in a world where there are not restrictions on what applications users
may install and run).

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