PM: Opportunistic suspend support.
in [Kernel]
|
Prev: direct-io: do not merge logically non-contiguous requests
Next: [PATCH] linux/elfcore.h: hide kernel functions
From: Neil Brown on 27 May 2010 03:40 On Wed, 26 May 2010 12:21:02 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 03:17 -0700, Arve Hjønnevåg wrote: > > > With a single suspend manager process that manages the suspend state you > > > can achieve the same goal. > > > > > > > Yes we don't need the /dev interface, but it is useful. Without it any > > program that needs to block suspend has to make a blocking ipc call > > into the suspend manager process. Android already does this for java > > code, but system processes written in C block suspend directly with > > the kernel since they cannot use the java APIs. > > So provide a C interface to it as well? > > Surely you can have the java thing have a unix socket or something a C > app can talk to. That shouldn't be hard at all. > > Or make the suspend manager a C proglet and provide a JNI interface, or > whatever. I fail to understand the modern fascination with complex IPC mechanisms. If you have a userspace process that initiates suspends, and you want other user-space processes to be able to block that suspend, then I would suggest the use of a lock-file. /var/run/suspend/blocked maybe. To block suspend, you open the file and get a read lock. To initiate a suspend you take a write-lock (blocking if necessary), then ask the kernel to suspend. To restrict access to particular users you use permissions - either group based or ACLs (or both). This is all easy to do from C or python or perl or presumably even java.. (I use this mechanism on my Freerunner and even have shell scripts that happily prevent suspend). NeilBrown -- 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 27 May 2010 05:10 On Thu, May 27, 2010 at 1:17 AM, Bernd Petrovitsch <bernd(a)petrovitsch.priv.at> wrote: > On Mit, 2010-05-26 at 13:23 -0500, James Bottomley wrote: >> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote: > [...] >> > Darn, _we_ have to deal with that forever as it sets a crappy user >> > space ABI in stone. >> >> I really don't see how it is ... the ABI comes with a switch that allows >> it to be disabled, so only platforms wishing to use it have to support >> it. �Even on those platforms that do support it, we can translate most > > You completely missed the point: The crappy user interface - and > interferences with pother subsystems - must be maintained for ages - and > that is independent if one uses it or not. Even worse if it's not widely > used. When (or if) the time comes that suspend is no longer useful, this api becomes a NOP. > >> of it into pm QoS stuff and if one day someone solves the rogue app >> problem, we can migrate over. > > If it's so important for Android and no one else, Android can carry it > out of tree. > This is not only important for Android. If you use suspend on a current Linux system you run the risk of loosing wakeup events. If you have wakeup events that you cannot afford to lose your only option is to never suspend. On some hardware (e.g. x86) the cost of not suspending is always huge, on other hardware (many ARM SOCs) the cost is only huge if your apps behave poorly. -- 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: Bernd Petrovitsch on 27 May 2010 05:20 On Mit, 2010-05-26 at 13:23 -0500, James Bottomley wrote: > On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote: [...] > > Darn, _we_ have to deal with that forever as it sets a crappy user > > space ABI in stone. > > I really don't see how it is ... the ABI comes with a switch that allows > it to be disabled, so only platforms wishing to use it have to support > it. Even on those platforms that do support it, we can translate most You completely missed the point: The crappy user interface - and interferences with pother subsystems - must be maintained for ages - and that is independent if one uses it or not. Even worse if it's not widely used. > of it into pm QoS stuff and if one day someone solves the rogue app > problem, we can migrate over. If it's so important for Android and no one else, Android can carry it out of tree. Bernd -- Bernd Petrovitsch Email : bernd(a)petrovitsch.priv.at LUGA : http://www.luga.at -- 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: Alan Stern on 27 May 2010 10:10 On Wed, 26 May 2010, Arve Hj�nnev�g wrote: > >> > And even if it isn't, so what? �What's wrong with looping behavior? > >> > >> It is a significant power drain. > > > > Not in the situation I was discussing. > > > > If you meant it spend most of the time suspended, then I agree. It > only wastes power when a driver blocks suspend by returning an error > from its suspend hook and we are forced to loop doing no useful work. Exactly the same as the in-kernel opportunistic suspend implementation. Alan Stern -- 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: Dmitry Torokhov on 27 May 2010 14:20
On Wed, May 26, 2010 at 05:52:40PM -0700, Arve Hj�nnev�g wrote: > 2010/5/26 Alan Stern <stern(a)rowland.harvard.edu>: > > On Wed, 26 May 2010, Arve Hj�nnev�g wrote: > > > >> > I must be missing something. �In Arve's patch 1/8, if the system is in > >> > opportunistic suspend, and a wakeup event occurs but no suspend > >> > blockers get enabled by the handler, what causes the system to go back > >> > into suspend after the event is handled? �Isn't that a loop of some > >> > sort? > >> > > >> > >> Yes it is a loop. I think what you are missing is that it only loops > >> repeatedly if the driver that aborts suspend does not use a suspend > >> blocker. > > > > You mean "the driver that handles the wakeup event". �I was asking what > > happened if suspend succeeded and then a wakeup occurred. �But yes, if > > a suspend blocker is used then its release causes another suspend > > attempt, with no looping. > > > >> > And even if it isn't, so what? �What's wrong with looping behavior? > >> > >> It is a significant power drain. > > > > Not in the situation I was discussing. > > > > If you meant it spend most of the time suspended, then I agree. It > only wastes power when a driver blocks suspend by returning an error > from its suspend hook and we are forced to loop doing no useful work. > If driver refuses to suspend that means there are events that need processing. I fail to see why it would be called "looping doing no useful work". -- Dmitry -- 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/ |