[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1005271329460.3239-100000@iolanthe.rowland.org>
Date: Thu, 27 May 2010 13:32:21 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Peter Zijlstra <peterz@...radead.org>
cc: Matthew Garrett <mjg59@...f.ucam.org>,
LKML <linux-kernel@...r.kernel.org>,
Florian Mickler <florian@...kler.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
<felipe.balbi@...ia.com>, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
> > > Opportunistic suspend is just a deep idle state, nothing else.
> >
> > No. The useful property of opportunistic suspend is that nothing gets
> > scheduled. That's fundamentally different to a deep idle state.
>
> I think Alan and Thomas but certainly I am saying is that you can get to
> the same state without suspend.
>
> Either you suspend (forcefully don't schedule stuff), or you end up
> blocking all tasks on QoS/resource limits and end up with an idle system
> that goes into a deep idle state (aka suspend).
>
> So why isn't blocking every task on a QoS/resource good enough for you?
On some platforms (like those with ACPI), deeper power-savings are
available by using forced suspend than by using idle. That used to be
the case on Android. Arve has said that it isn't necessarily true any
more, but that's the way their software is set up.
Alan Stern
--
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/
Powered by blists - more mailing lists