Re: [RFD] Automatic suspend

["Rafael J. Wysocki" <rjw@sisk.pl>]

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