[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: James Bottomley on 2 Jun 2010 16:50 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(a)suse.de> 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. > <disclaimer: just from what I read> > Provided you can reach the same power state from idle, current suspend > could probably also be implemented by just the freezing part and a hint > to the idle-loop to provide accelerated fall-through to lowest power. > </disclaimer> > > At that point, you could probably merge the constraints. > > But the freezing part is also the hard part, isn't it? (I have no > idea. Thomas seems to think about cgroups for that and doing smth about the timers.) Um, well, as I said, I think using suspend from idle and freezer is longer term. I think if we express the constraints as qos android can then use them to gate when to enter S3 .. which is functionally equivalent to suspend blockers. And the vanilla kernel can use them to gate power states for the drivers in suspend from idle. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 2 Jun 2010 17:00 On Wednesday 02 June 2010, Neil Brown wrote: > On Tue, 1 Jun 2010 10:47:49 -0400 (EDT) > Alan Stern <stern(a)rowland.harvard.edu> wrote: .... > So yes, there are different use cases and we should support all of them, > both "I shut the lid and my laptop really stays asleep" and "I never miss a > TXT because my phone went to sleep at a bad time". The process that > initiates the suspend has a role in choosing what can wake it up. You'd need to add some all new infrastructure for that, because right now only hardware wakeup signals are regarded as (system) wakeup events (they are either interrupts or things like PCI PMEs, possibly translated to some platform signals like GPIOs or something). I think I know how to prevent these hardware wakeup events from being lost (such that the entire suspend will be aborted if one of them happens during suspend), but for the handling of more generally defined wakeup events we'd need to provide user space with information on what wakeup events are available and how to enable and disable them, among other things. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 2 Jun 2010 18:00 2010/6/2 mark gross <640e9920(a)gmail.com>: > On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hj�nnev�g wrote: >> On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920(a)gmail.com> wrote: >> > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote: >> ... >> >> +static void update_target_val(int pm_qos_class, s32 val) >> >> +{ >> >> + � � s32 extreme_value; >> >> + � � s32 new_value; >> >> + � � extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value); >> >> + � � new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value); >> >> + � � if (extreme_value != new_value) >> >> + � � � � � � atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value); >> >> +} >> >> + >> > >> > Only works 1/2 the time, but I like the idea! >> > It fails to get the righ answer when constraints are reduced. �But, this >> > idea is a good improvement i'll roll into the next pm_qos update! >> > >> >> I think it would be a better idea to track your constraints with a >> sorted data structure. That way you can to better than O(n) for both >> directions. If you have a lot of constraints with the same value, it >> may even be worthwhile to have a two stage structure where for >> instance you use a rbtree for the unique values and list for identical >> constraints. > > I don't agree, we went through this tree vrs list discussion a few times > before in other areas of the kernel. �Wherever the list tended to be > short, a simple list wins. �However; we can try it, after we have some > metrics and stress test cases identified we can measure its effectivenes > against. > The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill. -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 2 Jun 2010 18:10 On Wednesday 02 June 2010, mark gross wrote: > On Tue, Jun 01, 2010 at 08:50:02PM -0700, Arve Hj�nnev�g wrote: > > On Tue, Jun 1, 2010 at 7:05 AM, mark gross <640e9920(a)gmail.com> wrote: > > > On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote: > > ... > > >> +static void update_target_val(int pm_qos_class, s32 val) > > >> +{ > > >> + s32 extreme_value; > > >> + s32 new_value; > > >> + extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value); > > >> + new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value); > > >> + if (extreme_value != new_value) > > >> + atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value); > > >> +} > > >> + > > > > > > Only works 1/2 the time, but I like the idea! > > > It fails to get the righ answer when constraints are reduced. But, this > > > idea is a good improvement i'll roll into the next pm_qos update! > > > > > > > I think it would be a better idea to track your constraints with a > > sorted data structure. That way you can to better than O(n) for both > > directions. If you have a lot of constraints with the same value, it > > may even be worthwhile to have a two stage structure where for > > instance you use a rbtree for the unique values and list for identical > > constraints. > > I don't agree, we went through this tree vrs list discussion a few times > before in other areas of the kernel. Wherever the list tended to be > short, a simple list wins. However; we can try it, after we have some > metrics and stress test cases identified we can measure its effectivenes > against. How many different values are there to handle? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 2 Jun 2010 18:30
On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley <James.Bottomley(a)suse.de> 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(a)suse.de> 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? Because the driver gets called on suspend which gives it a change to stop using it. > > 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. > The suspend block patchset only deals with suspend, not low power idle modes. The original wakelock patchset had two wakelock types, idle and suspend. >> 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. > The i2c bus on the Nexus One is used by the other core to turn off the power you our core when we enter the lowest power mode. This means that we cannot enter that low power mode while the i2c bus is active, so we block low power idle modes. At some point we also tries to block suspend in this case, but this caused a lot of failed suspend attempts since the frequency scaling code would try to ramp up while freezing processes which in turn aborted the process freezing attempts. >> <disclaimer: just from what I read> >> Provided you can reach the same power state from idle, current suspend >> could probably also be implemented by just the freezing part and a hint >> to the idle-loop to provide accelerated fall-through to lowest power. >> </disclaimer> >> >> At that point, you could probably merge the constraints. >> >> But the freezing part is also the hard part, isn't it? (I have no >> idea. Thomas seems to think about cgroups for that and doing smth about the timers.) > > Um, well, as I said, I think using suspend from idle and freezer is > longer term. �I think if we express the constraints as qos android can > then use them to gate when to enter S3 .. which is functionally > equivalent to suspend blockers. �And the vanilla kernel can use them to > gate power states for the drivers in suspend from idle. > > James > > > -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |