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

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

Message-Id: <201005060251.18656.rjw@sisk.pl>
Date:	Thu, 6 May 2010 02:51:18 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	tytso@....edu, Matthew Garrett <mjg@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Brian Swetland <swetland@...gle.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"Arve Hj?nnev?g" <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	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>, rebecca@...roid.com
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Thursday 06 May 2010, Mark Brown wrote:
> On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote:
> 
> > set up that way).  Even without the patchset you may implement a power
> > manager in user space that will suspend the system whenever it thinks it's
> > idle.
> 
> Clearly, but...
> 
> > On Thursday 06 May 2010, Mark Brown wrote:
> 
> > > In the primary existing application this change interoperates very poorly
> > > with at least the current audio subsystem since that handles suspend by
> > > ceasing all activity and powering as much as it can off, which is sensible for
> > > manual only suspends but highly undesirable for opportunistic suspend in
> > > phones.
> 
> > You said that there's no fundamental difference between manual and
> > opportunistic suspend.  It only matters what _you_ are going to use suspend
> > for.  I agree that at the moment it's not suitable for aggressive power
> > management in phones because of the audio problem, but that applies to
> > "manual" as well as to "opportunistic" suspend.
> 
> ...on the other hand there's exactly one existing application for this,
> and that's the one that's most likely to run into problems since it's a
> phone OS and aggressive power management is pretty important for phones.
> 
> Merging a feature into mainline makes it much more something which one
> would expect to play nicely with the rest of the kernel - if it's
> something that isn't part of the standard kernel or userspaces it's much
> less surprising that additional changes may be required to produce a
> well integrated system.
> 
> > You're saying that suspend is not suitable for one particular purpose in its
> > current form, which is entirely correct, but that doesn't imply that the
> > patchset is wrong.
> 
> As I keep saying I agree that merging this is reasonable given the
> additional power savings it brings in practical systems today.  As I
> also keep saying I do want to have some understanding about what the
> story is for dealing with the problems so that people can easily use
> this feature out of the box.
> 
> Like I say, my current impression is that the best approach is for
> affected subsystems or drivers to implement a custom solution - does
> that match your understanding and that of the other PM maintainers?

I agree that this appears to be the best approach for the time being, although
I can only speak for myself.

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/