Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Felipe Contreras on 11 Aug 2010 21:30 On Thu, Aug 12, 2010 at 4:06 AM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Thu, Aug 12, 2010 at 03:28:00AM +0300, Felipe Contreras wrote: >> On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney >> <paulmck(a)linux.vnet.ibm.com> wrote: >> > On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote: >> >> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney >> >> <paulmck(a)linux.vnet.ibm.com> wrote: >> >> > But wouldn't an office suite run as a power-oblivious application on an >> >> > Android device? After all, office applications do not need to run when >> >> > the screen is turned off, so these the applications do not need to use >> >> > suspend blockers. >> >> >> >> Ideally the system would be suspended even when the screen is on. If >> >> there are no "trusted" applications running at the same time, then >> >> openoffice wouldn't load at all. Right? >> > >> > My understanding is that Android systems in fact do not suspend when >> > the screen is on, and that most (perhaps all) other systems do not >> > opportunistically suspend at all. There has been some speculation about >> > what a hypothetical Android having a non-volatile display might do, >> > but as far as I know, this is just speculation. >> >> I have a desktop system in mind. If opportunistic suspend is only >> triggered when the display is off, then it's no good for normal usage, >> and therefore dynamic PC needs to get its act together... specially >> for laptops. > > If I understand you correctly, you are saying that both opportunistic > suspend and dynamic power control should be used together, with dynamic > power control being used for short non-busy periods (as in between > keystrokes) and opportunistic suspend being used for longer non-busy > periods (as in while grabbing a coffee). That combination of usage > sounds promising to me. No. In the future x86 will be fixed, but for now let's imagine an ARM laptop. > That said, I don't know that anyone has really sat down and thought > through how one might apply suspend blockers to a desktop system. > I suspect that there are several ways to go about it. Think in terms of an ARM laptop. What good is opportunistic suspend if it's not going to help when the laptop is being used? -- Felipe Contreras -- 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: Paul E. McKenney on 11 Aug 2010 23:50 On Thu, Aug 12, 2010 at 04:25:21AM +0300, Felipe Contreras wrote: > On Thu, Aug 12, 2010 at 4:06 AM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: > > On Thu, Aug 12, 2010 at 03:28:00AM +0300, Felipe Contreras wrote: > >> On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney > >> <paulmck(a)linux.vnet.ibm.com> wrote: > >> > On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote: > >> >> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney > >> >> <paulmck(a)linux.vnet.ibm.com> wrote: > >> >> > But wouldn't an office suite run as a power-oblivious application on an > >> >> > Android device? �After all, office applications do not need to run when > >> >> > the screen is turned off, so these the applications do not need to use > >> >> > suspend blockers. > >> >> > >> >> Ideally the system would be suspended even when the screen is on. If > >> >> there are no "trusted" applications running at the same time, then > >> >> openoffice wouldn't load at all. Right? > >> > > >> > My understanding is that Android systems in fact do not suspend when > >> > the screen is on, and that most (perhaps all) other systems do not > >> > opportunistically suspend at all. �There has been some speculation about > >> > what a hypothetical Android having a non-volatile display might do, > >> > but as far as I know, this is just speculation. > >> > >> I have a desktop system in mind. If opportunistic suspend is only > >> triggered when the display is off, then it's no good for normal usage, > >> and therefore dynamic PC needs to get its act together... specially > >> for laptops. > > > > If I understand you correctly, you are saying that both opportunistic > > suspend and dynamic power control should be used together, with dynamic > > power control being used for short non-busy periods (as in between > > keystrokes) and opportunistic suspend being used for longer non-busy > > periods (as in while grabbing a coffee). �That combination of usage > > sounds promising to me. > > No. In the future x86 will be fixed, but for now let's imagine an ARM laptop. Hmmm... OK... > > That said, I don't know that anyone has really sat down and thought > > through how one might apply suspend blockers to a desktop system. > > I suspect that there are several ways to go about it. > > Think in terms of an ARM laptop. What good is opportunistic suspend if > it's not going to help when the laptop is being used? For when the laptop is not being used, presumably. Thanx, Paul -- 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: Felipe Contreras on 12 Aug 2010 06:40 On Thu, Aug 12, 2010 at 6:44 AM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Thu, Aug 12, 2010 at 04:25:21AM +0300, Felipe Contreras wrote: >> Think in terms of an ARM laptop. What good is opportunistic suspend if >> it's not going to help when the laptop is being used? > > For when the laptop is not being used, presumably. Right, but if you have to optimize for dynamic PM anyway for normal usage, how much would you gain by opportunistic suspend? As it has been explained before, there's a point of diminishing returns: http://article.gmane.org/gmane.linux.kernel/995525 http://article.gmane.org/gmane.linux.ports.arm.omap/37982 Now, how much would dynamic PM have progressed by the time we start thinking on opportunistic suspend on laptops (ARM, or fixed PM), 10 seconds idle? 1 minute idle? Would it make sense to rewrite *all* user-space in order to archive that little extra performance, *or* would it make more sense to keep investing on dynamic PM which we have to do anyway? All this has already been explained. BTW, the gain is even less if you consider that laptops already automatically go to suspend after a while, so the gains of opportunistic suspend would have to be measured only for a small period of time (like 30 min or so). -- Felipe Contreras -- 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: Theodore Tso on 12 Aug 2010 06:50 Felipe, One thing I'm not clear on --- what's your goal? Is your goal to keep suspend-blockers out of the kernel? Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them? Is it to push some other agenda? Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel? You seem to be arguing quite passionately, but I'm not sure what you're trying to do. -- Ted -- 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: Felipe Contreras on 12 Aug 2010 07:20
On Thu, Aug 12, 2010 at 1:47 PM, Theodore Tso <tytso(a)mit.edu> wrote: > One thing I'm not clear on --- what's your goal? Is your goal to keep suspend-blockers out of the kernel? Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them? Is it to push some other agenda? Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel? My goal is to shine light. I've heard many invalid arguments in favor of suspend blockers, I want to shut them down. In my mind it's crystal clear that independently of what opportunistic suspend is supposed to be fixing, the fact of the matter is that it's not a silver bullet as it's claimed to be. So far, nobody has refuted these: 1) opportunistic suspend needs a good behaved user-space to work properly 2) if suspend blockers are enabled in a system, *all* user-space must implement them to work correctly 3) implementing suspend blockers in user-space is not a straight-forward task 4) there's a point where sleeping (not doing work) has diminished returns So, as the length of this thread has shown, the benefits of opportunistic suspend are *dubious* at best, and more likely not worth the changes needed in user-space which eventually will get pretty close to what suspend blockers can achieve even in ideal circumstances by just doing dynamic PM. -- Felipe Contreras -- 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/ |