Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 02 Jun 2010 15:41:11 -0500
James Bottomley <James.Bottomley@xxxxxxx> wrote:

> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
> > On Wed, 02 Jun 2010 10:05:11 -0500
> > James Bottomley <James.Bottomley@xxxxxxx> wrote:
> > 
> > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
> > > > No, they have to be two separate constraints, otherwise a constraint
> > > > to block suspend would override a constraint to block a low power idle
> > > > mode or the other way around.
> > > 
> > > Depends.  If you block the system from going into low power idle, does
> > > that mean you still want it to be fully suspended?
> > > 
> > > If yes, then we do have independent constraints.  If not, they have a
> > > hierarchy:
> > > 
> > >       * Fully Interactive (no low power idle or suspend)
> > >       * Partially Interactive (may go into low power idle but not
> > >         suspend)
> > >       * None (may go into low power idle or suspend)
> > > 
> > > Which is expressable as a ternary constraint.
> > > 
> > > James
> > > 
> > 
> > But unblocking suspend at the moment is independent to getting idle.
> > If you have the requirement to stay in the highest-idle level (i.e.
> > best latency you can get) that does not (currently) mean, that you can
> > not suspend.
> 
> I don't understand that as a reason.  If we looks at this a qos
> constraints, you're saying that the system may not drop into certain low
> power states because it might turn something off that's currently being
> used by a driver or a process.  Suspend is certainly the lowest state of
> that because it turns everything off, why would it be legal to drop into
> that?
> 
> I also couldn't find this notion of separation of idleness power from
> suspend blocking in the original suspend block patch set ... if you can
> either tell me where it is, or give me an example of the separated use
> cases, I'd understand better.
> 
> > To preserve that explicit fall-through while still having working
> > run-time-powermanagement I think the qos-constraints need to be
> > separated. 
> 
> OK, as above, why?  or better yet, just give an example.

Hm. Maybe it is me who doesn't understand. 

With proposed patchset: 
1. As soon as we unblock suspend we go down.  (i.e. suspending)
2. While suspend is blocked, the idle-loop does it's things. (i.e.
runtime power managment -> can give same power-result as suspend)

possible cases:
1: 
   - qos-latency-constraints: 1ms,  [here: forbids anything other than
     C1 idle state.]
   - suspend is blocked

2: - qos latency-constraints: as in 1
   - suspend unblocked

3: - qos latency-constraints: infinity, cpu in lowest power state.
   - suspend is blocked

4: - qos latency-constraints: infinity, cpu in lowest power state.
   - suspend unblocked


in case 2 and 4 we would suspend, regardeless of the qos-latency.

in case 1 and 3 we would stay awake, regardeless of the qos-latency
constraint.


If only one constraint, then case 2 (or 3) wouldn't be possible. But it
is possible now. 

A possible use case as an example?
(hmm... i'm trying my imagination hard now): 
	Your sound needs low latency, so that could be a cause for the
	qos-latency constraint. 

	And unblocking suspend could nonetheless happen:
	For example... you have an firefox open and don't want to
	prevent suspend for that case when the display is turned off


Cheers,
Flo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/