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]

Message-Id: <200902192215.18365.rjw@sisk.pl>
Date:	Thu, 19 Feb 2009 22:15:16 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Arjan van de Ven <arjan@...radead.org>,
	Kyle Moffett <kyle@...fetthome.net>,
	Oliver Neukum <oliver@...kum.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	mark gross <mgross@...ux.intel.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 Thursday 19 February 2009, Alan Stern wrote:
> On Thu, 19 Feb 2009, Rafael J. Wysocki wrote:
> 
> > On Thursday 19 February 2009, Alan Stern wrote:
> > > On Thu, 19 Feb 2009, Rafael J. Wysocki wrote:
> > > 
> > > > > If some devices are autosuspended after a local inactivity timeout, I
> > > > > don't want to wait for those devices to autosuspend if I know the code
> > > > > that needed to run is done. This could cause delays in the normal
> > > > > case,
> > > > 
> > > > Isn't it a matter of adjusting the inactivity timeouts in a suitable way?
> > > 
> > > It's not that simple.  A single device driver has a very local view, 
> > > not suitable for deciding whether the entire system should go to sleep.
> > > 
> > > So for example, a disk driver might think it's appropriate to spin down 
> > > the disk after 10 seconds of inactivity.  But an overall system monitor 
> > > might realize that nothing is going on right now and want to put the 
> > > system to sleep immediately, without waiting the 10 seconds for the 
> > > disk to autosuspend.
> > 
> > Now, the question is what criteria would the overall system monitor use to make
> > such a decision.
> > 
> > > > > and it could prevent suspend if a background process (not using
> > > > > wakelocks) is accessing a disk more frequently than its idle timeout.
> > > > 
> > > > Well, actually, shouldn't it prevent suspend from happening?  Arguably, it just
> > > > means that the disk is continuously being accessed with respect to the inactive
> > > > timeout granularity.
> > > 
> > > That's true, but it shows the problem of making the autosleep decision
> > > based on disk activity.  An auto-sleep should not have to wait for
> > > every device (or some suitable subset) to become idle for some minimum
> > > time; it should be able to kick in at short notice.
> > 
> > Again, the decision to trigger automatic suspend has to be based on some
> > well defined criteria and the (in)activity of devices seems to be one of them.
> 
> I don't know what criteria the system monitor would use.

I don't know either and this is the whole point.  They need to be specified
somehow and I'm not sure if "we suspend if no one is holding a wakelock" is the
right approach.

> It might have to be platform-specific.  The Android people seem to have a
> pretty good idea of what criteria will work for them.

I'd really like to know in what situations Androind is supposed to suspend
automatically.

> Inactivity of devices isn't always a good criterion.  There might be a
> background task which wakes up every few seconds to do something as
> long as the system is awake, thereby keeping some device always active.  
> The activity from this background task shouldn't prevent an auto-sleep.

In fact there are two problems here.  First, there may be a task preventing
some devices from becoming inactive (like syslog).  Second, there may be
a task waiting for something important to happen, such that automatic suspend
cannot be triggered while it's waiting.  In both cases, IMO, the kernel is not
in a point to decide whether to suspend or not, because the user space knows
better.

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/