From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757767AbZBSVQE (ORCPT ); Thu, 19 Feb 2009 16:16:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755506AbZBSVPx (ORCPT ); Thu, 19 Feb 2009 16:15:53 -0500 Received: from ogre.sisk.pl ([217.79.144.158]:51061 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755021AbZBSVPx (ORCPT ); Thu, 19 Feb 2009 16:15:53 -0500 From: "Rafael J. Wysocki" To: Alan Stern Subject: Re: [RFD] Automatic suspend Date: Thu, 19 Feb 2009 22:15:16 +0100 User-Agent: KMail/1.11.0 (Linux/2.6.29-rc5-tst; KDE/4.2.0; x86_64; ; ) Cc: Arve =?iso-8859-1?q?Hj=F8nnev=E5g?= , "Woodruff, Richard" , Arjan van de Ven , Kyle Moffett , Oliver Neukum , Benjamin Herrenschmidt , pm list , LKML , Pavel Machek , Nigel Cunningham , Matthew Garrett , mark gross , Uli Luckas , Igor Stoppa , Brian Swetland , Len Brown References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902192215.18365.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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