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]

Date:	Mon, 3 May 2010 23:18:35 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Kevin Hilman <khilman@...prootsystems.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 Monday 03 May 2010, Mark Brown wrote:
> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:
> 
> > At least from the kernel perspective, both suspend blockers and
> > runtime PM have the same goal.  Given that, which framework should the
> > driver writer target?  Both?  Seems like duplicate effort.  Using
> > suspend blockers assumes the system is in opportunitstic suspend mode
> > and (at least in the keypad example given) assumes a suspend-blocker
> > aware userspace (Android.) Without both, targeted power savings will
> > not be acheived.
> 
> The other concern here is that for many mobile systems the actual
> semantic intended by "suspend" as it's currently used is more runtime PM
> like than full suspend - the classic example of this is that when
> suspending while on a call in a phone you don't want to suspend the
> modem or audio CODEC, you want to leave them running.  If you use a full
> system suspend then the drivers for affected components have to play
> guessing games (or add currently non-standard knobs for apps to twiddle)
> to decide if the system intends them to actually implement the suspend
> or not but with runtime PM it all falls out very naturally without any
> effort on the part of the driver.
> 
> > To me, runtime PM is a generic and flexible approach that can be used
> > with any userspace.  Driver writers should not have to care whether
> > the system is in "opportunistic" mode or about whether userspace is
> > suspend blocker capable.  They should only have to think about when
> > the device is (or should be) idle.
> 
> I fully agree with this.  We do need to ensure that a runtime PM based
> system can suspend the CPU core and RAM as well as system suspend can
> but that seems doable.

I _think_ it would be hard at least.  On ACPI-based systems it's not doable at
all AFAICS.

However, the real question is whether or not the opportunistic suspend feature
is worth adding to the kernel as such and I think it is.

To me, it doesn't duplicate the runtime PM framework which is aimed at the power
management of individual devices rather than the system as a whole.

Thanks,
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/