linux-kernel - Re: [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] [thread-next>] [day] [month] [year] [list]

Message-Id: <201005050142.41537.rjw@sisk.pl>
Date:	Wed, 5 May 2010 01:42:41 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Brian Swetland <swetland@...gle.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Alan Stern <stern@...land.harvard.edu>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Paul Walmsley <paul@...an.com>, magnus.damm@...il.com,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Wednesday 05 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@...k.pl> writes:
> 
> > On Tuesday 04 May 2010, Mark Brown wrote:
> >> On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote:
> >> 
> >> > With opportunistic suspend, all of this flexibility is gone, and the
> >> > device/subsystem is told to go into the lowest power, highest latency
> >> > state, period.
> >> 
> >> Well, half the problem I have is that unfortunately it's not a case of
> >> doing that period.  The prime example I'm familiar with is that for
> >> understandable reasons users become irate when you power down the audio
> >> CODEC while they're in the middle of a call so if opportunistic PM is in
> >> use then the audio subsystem needs some additional help interpreting a
> >> suspend request so that it can figure out how to handle it.  Similar
> >> issues apply to PMICs, though less pressingly for various reasons.
> >> 
> >> Just to be clear, I do understand and mostly agree with the idea that
> >> opportunistic suspend presents a reasonable workaround for our current
> >> inability to deliver good power savings with runtime PM methods on many
> >> important platforms but I do think that if we're going to make this
> >> standard Linux PM functionality then we need to be clearer about how
> >> everything is intended to hang together.
> >
> > At the moment the rule of thumb is: if you don't need the opportunistic
> > suspend, don't use it.  It is not going to be enabled by default on anything
> > other than Android right now.
> 
> Sure, but there are driver authors and subsystem maintainers who care
> about optimal PM in "normal" Linux *and* in Android.
> 
> As a PM maintainer for an embedded platform (OMAP) used in both, I
> certainly care about both, so "disable it if you don't like it" is not
> really an option.
> 
> IMO, driver/subsystem authors should not have to care if the userspace
> is Android or not.  We should be working towards a world where Android
> is not a special case.

I agree, but "working on towards a world where ..." need not mean "be there
from day one" IMO.  Also, I guess you'll agree that using the same _binary_
kernel with Android and non-Android user spaces doesn't necessarily make sense
(regardless of the fact that Android kernels have hardware-specific board files
included), so probably you'll still disable opportunistic suspend building the
kernel for non-Android systems (at least for the time being).

It looks like you're thinking the opportunistic suspend somehow is (or can be
used as) a replacement for runtime PM, but this is not the case.  The reason
why it's not the case is that runtime PM works with the assumption that user
space is not frozen and it works on individual devices.

OTOH, generally, there is a limit on the amount of energy savings you can
achieve with runtime PM alone and something like the opportunistic suspend is
necessary to go beyond that limit.

Now, I can easily imagine using suspend blockers and runtime PM in the same
driver with the general rule that you'll probably want to call suspend_unblock()
whenever the device is suspended with the help of the runtime PM framework.
That really depends on the device and the driver in question, though.

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