>-----Original Message----- >From: Florian Mickler [mailto:florian@xxxxxxxxxxx] >Sent: Wednesday, June 02, 2010 4:06 PM >To: James Bottomley >Cc: Arve Hjønnevåg; Neil Brown; tytso@xxxxxxx; Peter Zijlstra; LKML; Alan >Cox; Gross, Mark; Thomas Gleixner; Linux OMAP Mailing List; Linux PM; >felipe.balbi@xxxxxxxxx >Subject: Re: [PATCH 0/8] Suspend block api (version 8) > >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 > > [mtg: ] This has been a pain point for the PM_QOS implementation. They change the constrain back and forth at the transaction level of the i2c driver. The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is. We've had a number of attempts at fixing this, but I think the proper fix is to bolt a "disable C-states > x" interface into cpu_idle that bypases pm_qos altogether. Or, perhaps add a new pm_qos API that does the equivalent operation, overriding whatever constraint is active. --mgross _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
