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

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] [day] [month] [year] [list]

Date:	Mon, 17 May 2010 16:04:21 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	Mike Chan <mike@...roid.com>, Vitaly Wool <vitalywool@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Arjan van de Ven <arjan@...radead.org>,
	Matthew Garrett <mjg@...hat.com>,
	Len Brown <len.brown@...el.com>,
	Jacob Pan <jacob.jun.pan@...ux.intel.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	linux-omap@...r.kernel.org,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Daniel Walker <dwalker@...eaurora.org>, tytso@....edu,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Geoff Smith <geoffx.smith@...el.com>,
	Tejun Heo <tj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
>
> The fundamental problem is one of idleness.  What we want is the
> system to be idle in order to hit the lowest power states.  We can't
> get there because the system is not truly idle.
>
> So, there are basically two solutions:
>
> 1) find and fix the problem spots so we can be idle more often
> 2) add a new definition of idle so we can be idle more often
>
> Opporuntistic suspend takes the second approach where the new
> definition of idle is "no suspend blockers held."
>
> Of course, I clearly prefer the former, but it's also becoming clear
> that since I'm the only one still whining about it, I must be too much
> of an idealist to keep hoping for it.

I'd love to see the former work, but it is not something that I think
is going to be fixed rapidly.  It potentially involves many different
subsystems, and still requires some need for managing arbitrary
userspace agents which may have non-ideal behaviors (if we're going to
solve the problem for general purpose devices that can run arbitrary
user-installed software).  Incremental improvements are great though
(for example, that we can now be in lowest power idle for periods
greater than 2 seconds due to the change in .32).

Even when operating in opportunistic suspend, it is still advantageous
for idle to be as idle as possible and we should keep working toward
that goal.  If we get to the point where the power difference between
suspend-in-idle and opportunistic suspend is zero, then we no longer
need the latter.

I don't think anybody on the Google/Android side is arguing that we
*shouldn't* pursue dynamic pm and overall making idle more idle more
of the time.  We're just saying that here and now we are not at the
ideal and opportunistic suspend gains us real power savings and is
useful.

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/