[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: Vitaly Wool on 29 May 2010 04:40 2010/5/28 Alan Cox <alan(a)lxorguk.ukuu.org.uk>: > Ok lets try and produce something more concrete. The control groups may > be the wrong tool but we've got several such tools already > > > Kernel involved > ---------------- > acquire: � � � � � � � �mark myself important (into cgroup important) > acquire(timeout) � � � �ditto, plus app timer/timeout handler > release: � � � � � � � �mark myself unimportant (into cgroup downtrodden) May we somehow live without acquire(timeout)? This is the feature that can screw up a lot of things with very complicated debugging options. ~Vitaly -- 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: Vitaly Wool on 29 May 2010 04:50 On Fri, May 28, 2010 at 2:52 PM, Brian Swetland <swetland(a)google.com> wrote: > I am quite willing to state that on both MSM and OMAP based Android > platforms, we've found that the suspend blocker model allows us to > obtain a lower average power draw than if we don't use it -- Mike Chan > provided some numbers earlier in another thread in the trivial device > idle case, the win is of course much larger in the case of several > poorly behaved apps being active. Without the clear description of the experiments, that statement proves just nothing other than your applications work better with your model, but I would expect that to be so without any experiments at all. ~Vitaly -- 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: Florian Mickler on 29 May 2010 05:00 On Sat, 29 May 2010 10:28:19 +0200 Florian Mickler <florian(a)mickler.org> wrote: > On Sat, 29 May 2010 02:42:35 +0300 > Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > > > On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa(a)nokia.com> wrote: > > > ext Brian Swetland wrote: > > >> How is it flawed? �Serious question. > > > > > > I would avoid repeating all the good arguments given so far, but to make it > > > short: > > > > > > * I believe runtime PM is a much better starting point (at least for the > > > type of HW targeted at mobile devices) because it mimics an always-on system > > > toward userspace, which requires less disruption in the way apps are > > > designed > > > > I agree. > > > > If I understand correctly, if we have a perfect user-space that only > > does work when strictly needed and trying to do it in bursts, then we > > would be reaching the lowest power state, and there would be no need > > for suspend. The problem is that Android's user-space is pretty far > > from that, so they said "let's segregate user-space and go to lower > > power mode anyway". > > This has already been mentioned (who knew?): Android doesn't > want to depend on userspace for this. there is an implicit "all of userspace" in there, btw.. > > Cheers, > Flo -- 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: Florian Mickler on 29 May 2010 05:10 On Sat, 29 May 2010 00:11:32 +0200 "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > Having reconsidered the suspend blockers idea I came to the conclusion that > in fact it was a workaround for three different problems. But it is also a change of paradigm. The scheduler should strive to have the system idle as long as possible to conserve battery. And everything that does not serve the purpose of the device has to be considered as not worth running, except if there are other purpose-fullfilling tasks to run anyway. > > Thanks, > Rafael cheers, Flo -- 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: Peter Zijlstra on 29 May 2010 06:50
On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote: > On Sat, 29 May 2010 00:11:32 +0200 > "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > > > > Having reconsidered the suspend blockers idea I came to the conclusion that > > in fact it was a workaround for three different problems. > > But it is also a change of paradigm. The scheduler should strive to > have the system idle as long as possible to conserve battery. And > everything that does not serve the purpose of the device has to be > considered as not worth running, except if there are other > purpose-fullfilling tasks to run anyway. No the purpose of the scheduler is to run tasks when they are runnable. Not to second guess whatever caused them to become runnable. If you start to randomly not run tasks, the inversion chaos that ensues is terrible. You can apply the regular means of alleviating that and that entails adding *-inheritance to all blockable resources. The -rt patch set is doing that in part. You really need to make applications not want to run and block on their own volition (in a resource free point) and otherwise make them block on something forcefully and disregard any malfunctioning that would result from that, and in extreme cases terminate (releasing all resources). But really Android shouldn't even need kernel support to do all this, since its hosted on this massive middle-ware that intercepts everything, called a Java Virtual Machine. Now, all I'm interested in is providing interfaces from the kernel where needed, so that userspace can be optimally frugal with power usage, and can monitor/contain badly behaving tasks. If Android is so set in its ways that they don't want to adopt (like saying Android requires suspend for power management) then they can go their own merry way and I'm not interested anymore (it would be a shame though). -- 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/ |