Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: david on 10 Aug 2010 14:10 On Tue, 10 Aug 2010, Matthew Garrett wrote: > On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote: >>> Hmmm... Exactly which part do you consider flawed? Let's take it >>> one sentence at a time. The devices that I know of that lack suspend >>> blockers also lack opportunistic suspend. Therefore, all applications on >>> such devices run as would an application that acquired a suspend blocker >>> when it started and did not release that suspend blocker until it exited. >>> Pretty straightforward. >> >> What do you mean by "opportunistic suspend", lots of systems drop into >> lowest power states whenever they can. "Suspend is different" is a bit of >> Android religion that I am dubious has any basis in reality as seen from >> the application end of the universe. >> >> You may also wish to review the earlier parts of the discussion where it >> was explicitly stated by several developers that they were using >> "suspend" type modes as power states already and not using suspend >> blockers. So it's being done, today on ARM and your statement is directly >> contradicting the code. Modern ARM processors and x86 MID devices can >> suspend and resume extremely fast (fast enough that the fact Linux x86 >> rewriting all the SMP alternatives on suspend/resume is a measurable >> problem). If this same property doesn't end up on big PC boxes in time >> then I'd be very surprised. At that point the openoffice with suspend >> blockers or oracle with suspend blockers question becomes rather relevant. > > There's a clear and absolute difference between system suspend and > entering the same hardware state from the idle loop. That difference is > that processes aren't scheduled until an explicit wakeup event occurs. > Android is entirely capable of entering the same low power state at idle > (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but > if you have more than 0 scheduling wakeups a second then your power draw > is going to be greater. > > I agree that we should be targetting 0 wakeups per second. I don't agree > that it's realistic to insist that a use model that assumes imperfect > software is an invalid use model. If the primary difference between sleep and suspend is not scheduling processes, instead of messing with oppurtinistic suspend/suspend blockers/wakelocks/etc, why not just 'temporarily' change the timer fuzz value to a very large value (say an hour). That would still let things like openoffice saves ahve a fair chance to trigger before the battery died completely, but would wake the system so infrequently that it will be effectivly the same as a full suspend. David Lang -- 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: Matthew Garrett on 10 Aug 2010 14:20 On Tue, Aug 10, 2010 at 11:07:20AM -0700, david(a)lang.hm wrote: > If the primary difference between sleep and suspend is not scheduling > processes, instead of messing with oppurtinistic suspend/suspend > blockers/wakelocks/etc, why not just 'temporarily' change the timer fuzz > value to a very large value (say an hour). That would still let things > like openoffice saves ahve a fair chance to trigger before the battery > died completely, but would wake the system so infrequently that it will > be effectivly the same as a full suspend. Because it only affects processes that sleep. It's a question of how much pathology you want to be able to tolerate. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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: david on 10 Aug 2010 14:30 On Tue, 10 Aug 2010, Matthew Garrett wrote: > On Tue, Aug 10, 2010 at 11:07:20AM -0700, david(a)lang.hm wrote: > >> If the primary difference between sleep and suspend is not scheduling >> processes, instead of messing with oppurtinistic suspend/suspend >> blockers/wakelocks/etc, why not just 'temporarily' change the timer fuzz >> value to a very large value (say an hour). That would still let things >> like openoffice saves ahve a fair chance to trigger before the battery >> died completely, but would wake the system so infrequently that it will >> be effectivly the same as a full suspend. > > Because it only affects processes that sleep. It's a question of how > much pathology you want to be able to tolerate. Standard system stats will show you hogs like this. The Android people claim that wakelock stats will let the user identify processes that prevent the system from suspending properly and then remove them. If this is the case, a process that never sleeps will be even easier to identify and even more obvious an offender. If that isn't enough, then you can go back to the other idea I advanced, having some way to tell the system not to consider some processes when trying to decide if the system should sleep or not. David Lang -- 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 10 Aug 2010 20:50 On Tue, Aug 10, 2010 at 03:44:05PM +0100, Alan Cox wrote: > Which reminds me. I forgot a very important way that user space signals > the kernel as to its intents. > > The kernel can see whether code is sleeping by choice or sleeping because > someone blocked it (eg a page fault). The kernel also knows a lot about > the event being waited for (much more so in -rt than base). > > We don't capture all of that info but it seems it would advance progress > in the right direction to do so better. As one approach of many, this makes a great deal of sense. 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: david on 10 Aug 2010 21:40
On Tue, 10 Aug 2010, Paul E. McKenney wrote: > On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote: >>> situation you call out can occur with manual suspend-to-RAM already: >>> the fact is that this is a design choice. You could indeed make a >> >> Losing data is a design choice ? The application set a timer, the OS >> shouldn't be ignoring it in that situation. It might want to delay it, it >> might want to warn the user its hogging things it shouldnt (powertop, >> battery usage monitors in Android etc) > > Hmmm... Let's put the two approaches side by side so that we can compare > them more easily: > > Opportunistic Suspend Idle + Timer Jitter > > Set timer Set timer > Suspend OS delays timer > Resume OS continues delaying timer > Timer fires Timer fires > > These two cases look quite similar to me. > > But as you say, the battery can run out. So let's add that to the > comparison: > > Opportunistic Suspend Idle + Timer Jitter > > Set timer Set timer > Suspend OS delays timer > Battery runs out Battery runs out > Data loss Data loss > > The two cases still look quite similar. You might note, quite correctly, > that the time between suspend and resume might be quite a bit longer than > the typical time that the OS delays a timer. But the power consumption > on some platforms is quite a bit lower in the suspend case than it is > in the delayed-timer case. it has been stated that the android can hit the exact same power state either with sleep or suspend, and that the same clock can wake it up (it appears as a timer expiring for sleep, or an alarm for suspend, but it's the same clock firing the signal) so in at least some cases the hardware supports doing both with equal efficiency. >>> But that doesn't guarantee that solutions developed for PCs and laptops >>> will be optimal (or even usable) on cellphones. Sufficient difference >> >> Your cellphone is to all intents a laptop from ten years ago, it even has >> a similar display resolution and internet availability. The underlying >> difference between the two is solely form factor - the laptop had a >> better keyboard. > > There are similarities and differences. You have called out some of > the similarities. Differences include the more-aggressive hardware > power management on cellphones, the greater number and variety of > hardware accelerators on cellphones, battery capacity, and, as you say, > physical size. People currently use cellphones differently than they > do laptops or desktops. The usage might converge, but we will see. > There is as much reason to expect increasing specialization as there > is to expect increasing convergence. You are talking about Android as if it was a cell phone only thing, it's not. there are shipping tablets (and I believe netbooks, i.e. laptops) running andoid. >>> As to busting all apps, lthough there have been situations where busting >>> all the apps turned out to be the right thing to do, I agree that these >>> situations are extremely rare. Such situations are usually associated >>> with the emergence of a new high-volume platform. >> >> Like Microsoft Windows 16bit co-operative multi-tasking ? It's rarely >> right. It's merely that in certain cases the value in the market is large >> enough that it can be used as a big stick to beat people into doing lots >> of usually wasted work. > > Interesting choice of example. I do well remember the Sequent hardware > guys' frustration when the old printer driver would monopolize the desktop > while printing their large documents. The fact was that Microsoft's > co-operative multi-tasking required all applications to be well behaved, > just as does your approach to power efficiency. and wakelocks require all applications that can take a wakelock be well behaved. and applications that do nt take a wakelock directly cannot expect to run unless something else takes a wakelock on their behalf David Lang -- 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/ |