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: Arve Hjønnevåg on 26 May 2010 06:20 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > On Wed, 2010-05-26 at 02:54 -0700, Arve Hj�nnev�g wrote: >> >> I'm not sure what you are proposing that we use instead. Both >> user-space and kernel code needs to block suspend. If we don't have >> suspend blockers in the kernel then user-space needs to poll when a >> driver blocks suspend by returning an error from its suspend hook. > > In particular I'm suggesting you ditch the /dev/suspend_block thing. > > 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. > When the suspend manager has a !0 busy-task count, it ensures the kernel > won't auto-suspend, when it again reaches a 0 busy-task count, it > re-instates the auto-suspend feature. > > That's pretty much what that device would do too. > > Ideally we would not do the auto-suspend thing at all and have > runtime-PM improved. Not running apps when they expect to run is like > the world turned upside down. > > 'Evil' apps could always report themselves as blocker anyway. > -- 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: Pekka Enberg on 26 May 2010 06:30 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. 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > 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. Yup, I don't quite get Arve's argument either. C code can interact with Java code (and vice versa) just fine in userspace. -- 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 26 May 2010 06:30 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. -- 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: Pekka Enberg on 26 May 2010 06:40 2010/5/26 Arve Hj�nnev�g <arve(a)android.com>: >> So provide a C interface to it as well? > > We could, but the result would be that any program that needs to block > suspend has to be android specific. Why? You could put the userspace daemon to tools/suspend-manager, for example? -- 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 26 May 2010 06:40
2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > 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? > We could, but the result would be that any program that needs to block suspend has to be android specific. > 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. > -- 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/ |