linux-kernel - Re: [RFD] Automatic suspend

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, 16 Feb 2009 22:48:32 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	mark gross <mgross@...ux.intel.com>,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Uli Luckas <u.luckas@...d.de>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	Brian Swetland <swetland@...gle.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: [RFD] Automatic suspend

On Monday 16 February 2009, Arjan van de Ven wrote:
> On Mon, 16 Feb 2009 00:10:15 +0100
> "Rafael J. Wysocki" <rjw@...k.pl> wrote:
> 
> > Hi,
> > 
> > The recent descussion about the Android PM patches sent by Arve shows
> > that there is a need to introduce a mechanism allowing us to:
> > (1) automatically put the system as a whole into a sleep state (eg.
> > suspend to RAM) when it is found to be "idle", where the meaning of
> > "idle" has to be defined too,
> > (2) put given subset of devices into low power states whenever they
> > are not used, without putting the entire system into a sleep state.
> 
> 
> For (2), for me the answer is very obvious:
> 
> The Device Driver needs to make the decision to put the device to sleep.
> There are no ifs and buts about this.
> 
> It's the driver who 
> a) knows if there's any activity, such as open users
> and 
> b) is in the right position to know how to put things to sleep.
> 
> Of course, the subsystem the driver belongs to can provide helpers
> (such as generic activity timeout handlers etc).

While I generally agree, there is a difficulty that the driver itself need not
have control over all of the bits needed to power manage the device.  For
example, we're going to make the PCI bus type handle the changing of PCI
devices' power states, so the registers used for this purpose will be
controlled by the PCI subsystem rather than by individual drivers.

In such cases we may need a mechanism by which the drivers can notify the
higher layer that the device is inactive, so that the higher layer can put it
into a low power state.

> For many cases, the drivers do this today already.
> There are cases where doing this has side effects, mostly in terms of
> latency. It is reasonable to have a general mechanism that provides a
> central mechanism to track tolerable latencies; in fact PMQOS provides
> this on a high level, and I can imagine that PMQOS needs to be extended
> to provide a wider range of type of latencies.

That indeed would be useful.

> Userland should never ever control the state of a device like this
> directly. It should do so by a) closing the device and b) setting
> latency / functional requirements.

The user, however, may want to forcibly put a device into a low power state
without stopping all of the applications that depend on it (eg. have it open).
Do you think that we shouldn't allow users to do such things?

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/