Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Paul E. McKenney on 9 Aug 2010 15:20 On Mon, Aug 09, 2010 at 11:28:02AM -0700, david(a)lang.hm wrote: > On Mon, 9 Aug 2010, Paul E. McKenney wrote: > > >On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote: > > > >[ . . . ] > > > >>>would agree that in the ideal world, it would be nice if you could > >>>have applications that make the correct performance/battery > >>>utilization tradeoff for devices running on 800 mWh batteries, 94,000 > >>>mWh batteries, and while running on the AC mains. But I don't believe > >>>that it's likely to be true, and if you want to try to beat up on > >>>application writers one at a time to be power optimized --- as far as > >>>I'm concerned, that's an argument *for* suspend blockers, since I'm > >>>not big believer in plans that begin, "First, you command the tides of > >>>the sea to go back", King Canute style. :-) > >> > >>Suspend blockers drive the system policy part way into the apps, that in > >>turn makes the apps very vulnerable to change in their environment because > >>you've specialised them. I am sure that in the Android world it's > >>considered fine, and that the marketing and business people even like > >>this binding together - but it doesn't generalise and will blow up in > >>people's faces in the future. > >> > >>To consider your tide analogy - suspend blockers is like trying to > >>program the waves individually. Show me a suspend blocker aware open > >>office patch 8) > > > >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. That said, I could easily imagine that significant > >work would be required to make OpenOffice run on Android, not due to > >suspend blockers, but rather due to Android's unusual user space. > > pick your application if you don't like the example. I like the office-suite example just fine. > but also, which android system should the applicaton be written for? > the phone with a 800maH battery or a larger device with a 94,000maH > battery? Does battery size make a difference in this particular case? > well bahaved applications (not doing unnecessary wakeups, etc) are > well bahaved, no matter what system they are on Yep. Your point being what exactly? That all applications should be required to be power-optimized, and that any technology that automates energy efficiency should be rejected out of hand? If so, please justify your position. > (explicitly setting > allowable timer fuzz is linux specific, but will again help on any > system) Setting aside the question of how timer fuzz will help on non-Linux systems if timer fuzz is specific to Linux... 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: Brian Swetland on 9 Aug 2010 15:40 On Mon, Aug 9, 2010 at 12:18 PM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> 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 > > I was waiting for soemone to leap down the pit I dug Office suites have > some quite important background activities. Consider the case of a power > oblivious Open Office. You type a critical document, you suspend, your > phone battery dies a bit later, you lost your document. Office suites do > timed backing up as one simple obvious example. That could become a power > aware behaviour but the truely power oblivious office suite is a myth. > >> the screen is turned off, so these the applications do not need to use >> suspend blockers. That said, I could easily imagine that significant >> work would be required to make OpenOffice run on Android, not due to >> suspend blockers, but rather due to Android's unusual user space. > > You are tightly linking suspend blockers with Android. If they were a > sensible general solution they would be generic not tied closely to > Android Doesn't the same problem exist on my linux laptop? I write out my manifesto in open office, close the lid of my laptop, the system suspends before my huge document finishes writing out, later my battery dies or I foolishly remove it or whatnot... the main difference seems to be that laptops, with their big 'ol batteries, are less aggressive about power management and the result is wider windows before and less frequent wakeups from suspend and thus better odds at missing the race condition. As Arve has pointed out previously, there are a number of uses for suspend blockers, even on plugged-into-the-wall systems -- take his example of wanting his mythtv backend to power down when not busy, but never power down when he happens to be using it on console, or issues with multiple services that want to wake up and keep the device awake while working. Brian -- 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 9 Aug 2010 21:30 On Mon, 9 Aug 2010, Alan Cox 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 > > I was waiting for soemone to leap down the pit I dug Office suites have > some quite important background activities. Consider the case of a power > oblivious Open Office. You type a critical document, you suspend, your > phone battery dies a bit later, you lost your document. Office suites do > timed backing up as one simple obvious example. That could become a power > aware behaviour but the truely power oblivious office suite is a myth. this is a good example of why the office suite should be a privilaged application. If the system were to consider it privilaged, it could wake up when the timer is scheduled to fire to save the document. the office suite probably has a periodic timer that would fire every 10 min no matter what, but if there was a reason to change it, it could be modified to only setup the timer when the document is changed. If no changes can take place because the system is asleep, the timer never gets setup. 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 00:50 On Mon, Aug 09, 2010 at 08:18:22PM +0100, Alan Cox 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 > > I was waiting for soemone to leap down the pit I dug Office suites have > some quite important background activities. Consider the case of a power > oblivious Open Office. You type a critical document, you suspend, your > phone battery dies a bit later, you lost your document. Office suites do > timed backing up as one simple obvious example. That could become a power > aware behaviour but the truely power oblivious office suite is a myth. It is a sad day on LKML when we are busy digging pits for each other. On the other hand, I have seen far sadder days, and the pit you dug happens to lead somewhere useful. As Brian noted in his reply, the 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 PM-driving office application if you wished, or run the same application as a power-oblivious application. There is a slight difference in the contract with the user. Of course, it is quite clear which one -you- prefer, but preferences can vary. > > the screen is turned off, so these the applications do not need to use > > suspend blockers. That said, I could easily imagine that significant > > work would be required to make OpenOffice run on Android, not due to > > suspend blockers, but rather due to Android's unusual user space. > > You are tightly linking suspend blockers with Android. If they were a > sensible general solution they would be generic not tied closely to > Android Android is certainly where suspend blockers originated, and is to the best of my knowledge is still the only platform that uses them. But there is a first user of every new mechanism, and for some time that first user will by definition be the only user of that mechanism. So the fact that Android is most probably the only user of suspend blockers does not prove anything about whether or not suspend blockers are sensible. > Some of the other bad assumptions being made in this discussion: > > - That the phone is special. Todays Android phones are up with the PC's > of some years back (but with better graphics and more faster storage), > in a few more generations of the technology what will they look like ? > I'm sure that within a few years there will be people playing Warcraft > or similar on their phone in the train. Indeed, people have played games on their cellphones for some years. Not sure whether any of the games resembles World of Warcraft, but they probably soon will. If so, perhaps they will make use of significant hardware acceleration -- most other embedded systems do so. But that doesn't guarantee that solutions developed for PCs and laptops will be optimal (or even usable) on cellphones. Sufficient difference in scale can easily change the form of the optimal solution, so you have not yet made your case. (For that matter, you also haven't proven that adoption of suspend blockers or something like them depends on the assumption that cellphones are special.) > - That Android will continue to tbe offering the same services in future > as today. If it does it'll go the way of PalmOS and Symbian. Equally > you can't just bust all the apps as it changes I hope that no one is arguing that Android will remain unchanged, just as I hope no one would argue that Linux will remain unchanged. In fact, I am quite confident that both Linux and Android will continue to change. So exactly what point were you attempting to make here? 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. > As devices get more complex and varied you cannot afford to put the > detailed awareness of platform behaviour in the applications. It > doesn't scale. Android developers are haivng enough fun coping with all > the OS variants, customisations and new phones - and thats far less > variety than PC hardware. Generally the PC app folks are not having the > same level of problem - so ask why ? From what I can see, the Android developers are suffering less than the PC developers were suffering when the PC was the same age that Android is now. For that matter, suspend blockers don't put detailed awareness of platform behavior into apps. You must look to the heavily power-optimized apps to find that kind of awareness. > > On devices that do not have suspend blockers, a normal application runs > > in a manner similar to a hypothetical Android application that acquires > > a suspend blocker when it starts and holds that suspend blocker until > > it exits. In contrast with Android, this situation requires that each > > and every application be carefully written to avoid battery drain, > > which I suspect is what Ted is getting at with his King Canute analogy. > > Which is flawed and not the case. 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. As for the first part of the second sentence, you yourself have argued that each and every application should be carefully written to avoid battery drain (or, equivalently, to promote energy efficiency), so presumably the flaw does not reside there. That leaves the second half of that sentence, for which we both must defer to Ted. But Ted's intended meaning of his King Canute analogy does not affect the argument as to whether or not suspend blockers (or, again, something like them) are useful. > The same argument could be made for > multi-tasking > > DOS "Each application implements its own internal > multitasking/polling if needed" > > Windows 3.x "Each application has an event loop and is built > in a certain way" (the 'suspend blocker' mentality) > > Real OS "The scheduler operates in a manner which prevents > CPU hogs breaking the system or abusing it sufficiently to threaten its > functionality" I really do like this progression. I will return to it further down. > The same applies to power. Only the OS has the big picture and can hide > the hardware and general policy variety from the application. The OS can be said to possess the full picture only if the applications communicate their portion of the picture to the OS. Linux has quite a few APIs devoted to this sort of communication, many of them mandated by POSIX. Some people are proposing suspend blockers (or something like them) as another member of this set of APIs. > OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It > runs on virtual machines, it runs in power sensitive environments, it > runs in thermally constrained environments, it runs in I/O constrained > environments, it runs in latency constrained environments etc etc And there are numerous environments in which it will not run. So what? > All the same code, true some work has been done to make it behave > politely but the rest is down to the OS doing its job - deploying the > resources available while considering and obeying the constraints > present, in a manner which makes best use of the resources to achieve the > policy goals of the system. And if the work has not been done on the application, and if there is nothing like suspend blockers, the OS cannot do its job. So how exactly does this support your position? Which brings us to the progression from DOS to Windows 3.x to Real OS. Why can the Real OS's scheduler can operate "in a manner which prevents CPU hogs from breaking the system or abusing it sufficiently to threaten its functionality" while still allowing applications with special requirements to operate correctly? One reason is the advent of any number of APIs that communicate special properties of specific applications to the OS, including the old nice() system call, POSIX realtime, numerous facilities to communicate application properties to the VM system, and so on. Given this context, are you sure that suspend blockers are not the next step in the Real OS progression? Or some QoS mechanism that subsumes suspend blockers? However, there is a lot of negative experience around general-purpose QoS mechanisms -- you have to be quite careful in order to avoid spending more energy computing QoS than you would otherwise spend on the application's computations. The usual way out of this trap is to abandon generality in favor of exploiting the commonly occurring special cases. For all I know, raw suspend blockers might be the appropriate special case. > And not unsurprisingly that all starts to look like Stafford Beer's good > old viable systems model. Hmmm... I do like "Absolutum Obsoletum", especially if it really does translate to "If it works it's out of date." However, I am not at all convinced that it supports your position! ;-) 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: Alan Cox on 10 Aug 2010 04:30
> 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) > will by definition be the only user of that mechanism. So the fact > that Android is most probably the only user of suspend blockers does > not prove anything about whether or not suspend blockers are sensible. They don't appear to solve the constraints on power management that you have in other environments, nor do they happen to be conveniently backward compatible or available on other platforms - which makes code hard to port. > 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. > I hope that no one is arguing that Android will remain unchanged, just > as I hope no one would argue that Linux will remain unchanged. In fact, > I am quite confident that both Linux and Android will continue to change. > So exactly what point were you attempting to make here? That anything which ties to a particular style of behaviour and set of current usage assumptions is broken. If you rewrite all the apps to Android 2.1 and design in a single tasking model then you'll have to unrewrite half of it again when Android grows up. Ditto suspend blockers - encode too much policy in your apps and you lose the ability to change the environment under them. See the mess Microsoft got into with Win16 on Win32. Compare with Linux 32bit on Linux 64bit. > 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. > 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. > As for the first part of the second sentence, you yourself have argued > that each and every application should be carefully written to avoid > battery drain (or, equivalently, to promote energy efficiency), so No. I've argued that applications need to be generally well behaved, not keep waking up, not burn cpu - which is a generic property applicable on all environments not a specialisation. > > OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It > > runs on virtual machines, it runs in power sensitive environments, it > > runs in thermally constrained environments, it runs in I/O constrained > > environments, it runs in latency constrained environments etc etc > > And there are numerous environments in which it will not run. So what? It's one codebase for all of them and furthermore almost all of that was done by modifying only the OS. Linux learned to do power throttling without the app being involved, it learned to do virtualisation without the app being changed, it is learning (with -rt) to handle to do real time this way. > > All the same code, true some work has been done to make it behave > > politely but the rest is down to the OS doing its job - deploying the > > resources available while considering and obeying the constraints > > present, in a manner which makes best use of the resources to achieve the > > policy goals of the system. > > And if the work has not been done on the application, and if there is > nothing like suspend blockers, the OS cannot do its job. I don't see any evidence to support that claim. I see evidence that there are cases where apps wish to communicate their intentions around power more clearly but a suspend blocker is a crude single case hammer. Today most applications communicate their sleep/wake requirements fairly well by sleeping, by executing code and by setting timers/alarms. > Given this context, are you sure that suspend blockers are not the next > step in the Real OS progression? Or some QoS mechanism that subsumes > suspend blockers? However, there is a lot of negative experience > around general-purpose QoS mechanisms -- you have to be quite careful > in order to avoid spending more energy computing QoS than you would > otherwise spend on the application's computations. The usual way out of > this trap is to abandon generality in favor of exploiting the commonly > occurring special cases. For all I know, raw suspend blockers might be > the appropriate special case. For Android possibly and I've never had any objection to Android keeping suspend blockers in private patches. The claim is only a small number are needed in their kernel so its a tiddly patch and the patch context will no doubt keep it applying between releases and easy for them to maintain. For the rest of us - I see no evidence it's generally useful. A QoS API does appear to be generally useful but as you say you need to get the performance right. However you can also tackle that the way we tackle several other examples of one interface/many needs - such as schedulers, security models and the like. One interface to applications and one interface to drivers so that its easy to maintain and you don't end up with hooks all over the place for different things, then if it proves neccessary different implementations. So yes maybe Android would use a "qos_basic" which returns -EOPNOTSUPP to anything but a suspend blocker behaviour. The important thing about that is that my device drivers, my applications and my other platforms don't have to care that Android made this choice - they can still be generic code. That is why I used the Win16 example. The Win16 model encapsulated an implementation into the API. Had they followed a more conventional interface based around yielding then like MacOS they'd have had a far smoother move to pre-emptive MT. Alan -- 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/ |