Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Rafael J. Wysocki on 4 Aug 2010 20:20 On Thursday, August 05, 2010, david(a)lang.hm wrote: > On Thu, 5 Aug 2010, Rafael J. Wysocki wrote: > > > On Thursday, August 05, 2010, david(a)lang.hm wrote: > >> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote: > >> > >>> Subject: Re: Attempted summary of suspend-blockers LKML thread > >>> > >>> On Wednesday, August 04, 2010, david(a)lang.hm wrote: > >>>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote: > >>>>> In the suspend case, when you have frozen all applications, you can > >>>>> sequentially disable all interrupts except for a few selected ("wakeup") ones > >>>>> in a safe way. By disabling them, you ensure that the CPU will only be > >>>>> "revived" by a limited set of events and that allows the system to stay > >>>>> low-power for extended time intervals. > >>>> > >>>> the benifit of this will depend on what wakeups you are able to avoid by > >>>> putting the hardware to sleep. Depending on the hardware, this may be not > >>>> matter that much. > >>> > >>> That's correct, but evidently it does make a difference with the hardware > >>> Android commonly runs on. > >> > >> Ok, but is there a way to put some of this to sleep without involving a > >> full suspend? > > > > Technically, maybe, but we have no generic infrastructure in the kernel for that. > > There may be SoC-specific implementations, but nothing general enough. > > well, I know that we have specific cases of this (drive spin-down, cpu > speed, display backlight for a few examples), is it worth trying to define > a generic way to do this sort of thing? or should it be left as a > per-device thing (with per-device knobs to control it) The ability to put specific devices into low-power states in certain well-defined situations is clearly not sufficient. For one example, usually you can easily put an Ethernet adapter into a low-power state when the network cable is detached from it. It is not clear, however, what criteria should be used for deciding to put that adapter into the low-power state when the cable is attached to it (and open() has been called). To mimic suspend you'll have to be able to put _all_ devices into low-power states and shut down the interrupts that allow the monotonic clock to advance. That's much more than simple runtime power management of selected devices. > I thought I had seen discussion on how to define such a generic power > management interface, and I thought the results had been acceptable. If you have a pointer to that discussion, I'm interested. :-) Thanks, Rafael -- 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: Rafael J. Wysocki on 4 Aug 2010 20:20 On Thursday, August 05, 2010, david(a)lang.hm wrote: > On Thu, 5 Aug 2010, Rafael J. Wysocki wrote: > > > On Thursday, August 05, 2010, david(a)lang.hm wrote: > >> > >> My proposal would never freeze a subset of processes. > >> > >> what my proposal: > >> > >> only consider the activity of a subset of processes when deciding if we > >> should suspend or not. If the decision is to suspend, freeze everything. > > > > That alone doesn't allow you to handle the race Matthew was referring to > > (ie. wakeup event happening right after you've decided to suspend). > > > > A mechanism of making a decision alone is not sufficient, you also need a > > mechanism to avoid races between wakeup events and suspend process. > > > > I thought you just posted that there was a new feature that would be able > to abort the suspend and so that race was closed. Yes, you can use that for this purpose, but then you'd need a user space power manager who would decide whether or not to suspend. Then, however, the problem boils down to setting up appropriate communication between the power manager and the other applications in user space (ie. the kernel doesn't need to be involved in that at all). Thanks, Rafael -- 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 4 Aug 2010 20:20 On Wed, Aug 04, 2010 at 04:49:22PM -0700, david(a)lang.hm wrote: > On Wed, 4 Aug 2010, Paul E. McKenney wrote: > > >On Wed, Aug 04, 2010 at 04:23:43PM -0700, david(a)lang.hm wrote: > >>On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote: > >> > >>> > >>>We suspend as soon as no wakelocks are held. There is no delay. > >> > >>So, if I have a bookreader app that is not allowed to get the > >>wakelock, and nothing else is running, the system will suspend > >>immediatly after I click a button to go to the next page? it will > >>not stay awake to give me a chance to read the page at all? > >> > >>how can any application run without wakelock privilages? > > > >Isn't a wakelock held as long as the display is lit, so that the > >system would continue running as long as the page was visible? > > what holds this wakelock, and what sort of timeout does it have? > (and why could that same timeout be used in other ways instead) I defer to the Android guys on what exactly holds the display's wakelock. The timeout is the display-blank timeout. > how many apps really need to keep running after the screen blanks? > there are a few (audio output apps, including music player and > Navigation directions), but I don't have see a problem with them > being marked as the 'trusted' apps to pay attention instead. Downloading is another. The music player is an interesting example. It would be idle most of the time, given that audio output doesn't consume very much CPU. So you would not want to suspend the system just because there were no runnable processes. In contrast, allowing the music player to hold a wake lock lets the system know that it would not be appropriate to suspend. Or am I misunderstanding what you are proposing? > if the backlight being on holds the wakelock, it would seem that > almost every other use of the wakelock could (and probably should) > be replaced by something that tickles the display to stay on longer. The problem with this approach is that the display consumes quite a bit of power, so you don't want to leave it on unnecessarily. So if the system is doing something (for example, playing music) that does not require the display, you really want the display to be off. 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 4 Aug 2010 20:30 On Wed, 4 Aug 2010, Paul E. McKenney wrote: > On Wed, Aug 04, 2010 at 04:49:22PM -0700, david(a)lang.hm wrote: >> On Wed, 4 Aug 2010, Paul E. McKenney wrote: >> >>> On Wed, Aug 04, 2010 at 04:23:43PM -0700, david(a)lang.hm wrote: >>>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote: >>>> >>>>> >>>>> We suspend as soon as no wakelocks are held. There is no delay. >>>> >>>> So, if I have a bookreader app that is not allowed to get the >>>> wakelock, and nothing else is running, the system will suspend >>>> immediatly after I click a button to go to the next page? it will >>>> not stay awake to give me a chance to read the page at all? >>>> >>>> how can any application run without wakelock privilages? >>> >>> Isn't a wakelock held as long as the display is lit, so that the >>> system would continue running as long as the page was visible? >> >> what holds this wakelock, and what sort of timeout does it have? >> (and why could that same timeout be used in other ways instead) > > I defer to the Android guys on what exactly holds the display's > wakelock. The timeout is the display-blank timeout. > >> how many apps really need to keep running after the screen blanks? >> there are a few (audio output apps, including music player and >> Navigation directions), but I don't have see a problem with them >> being marked as the 'trusted' apps to pay attention instead. > > Downloading is another. this is definantly an interesting case, do you want an active network connection to keep the machine awake? if so do you want it for all network connections, or only for some... > The music player is an interesting example. It would be idle most > of the time, given that audio output doesn't consume very much CPU. > So you would not want to suspend the system just because there were > no runnable processes. In contrast, allowing the music player to > hold a wake lock lets the system know that it would not be appropriate > to suspend. > > Or am I misunderstanding what you are proposing? the system would need to be idle for 'long enough' (configurable) before deciding to suspend, so as long as 'long enough' is longer than the music player is idle this would not be a problem. >> if the backlight being on holds the wakelock, it would seem that >> almost every other use of the wakelock could (and probably should) >> be replaced by something that tickles the display to stay on longer. > > The problem with this approach is that the display consumes quite a > bit of power, so you don't want to leave it on unnecessarily. So if > the system is doing something (for example, playing music) that does > not require the display, you really want the display to be off. what percentage (and types) of apps are really useful with the display off. I think that there are relativly few apps that you really want to keep running if the display is off. 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: Rafael J. Wysocki on 4 Aug 2010 20:30
On Thursday, August 05, 2010, Arve Hj�nnev�g wrote: > On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote: > >> On Wednesday, August 04, 2010, Matthew Garrett wrote: > >> > No! And that's precisely the issue. Android's existing behaviour could > >> > be entirely implemented in the form of binary that manually triggers > >> > suspend when (a) the screen is off and (b) no userspace applications > >> > have indicated that the system shouldn't sleep, except for the wakeup > >> > event race. Imagine the following: > >> > > >> > 1) The policy timeout is about to expire. No applications are holding > >> > wakelocks. The system will suspend providing nothing takes a wakelock. > >> > 2) A network packet arrives indicating an incoming SIP call > >> > 3) The VOIP application takes a wakelock and prevents the phone from > >> > suspending while the call is in progress > >> > > >> > What stops the system going to sleep between (2) and (3)? cgroups don't, > >> > because the voip app is an otherwise untrusted application that you've > >> > just told the scheduler to ignore. > >> > >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to > >> avoid the race (if pm_wakeup_event() is called at 2)). > > > > Yes, I think that solves the problem. The only question then is whether > > How? By passing a timeout to pm_wakeup_event when the network driver > gets the packet or by passing 0. If you pass a timeout it is the same > as using a wakelock with a timeout and should work (assuming the > timeout you picked is long enough). If you don't pass a timeout it > does not work, since the packet may not be visible to user-space yet. Alternatively, pm_stay_awake() / pm_relax() can be used. > > it's preferable to use cgroups or suspend fully, which is pretty much up > > to the implementation. In other words, is there a reason we're still > > I have seen no proposed way to use cgroups that will work. If you > leave some processes running while other processes are frozen you run > into problems when a frozen process holds a resource that a running > process needs. > > > > having this conversation? :) It'd be good to have some feedback from > > Google as to whether this satisfies their functional requirements. > > > > That is "this"? The merged code? If so, no it does not satisfy our > requirements. The in kernel api, while offering similar functionality > to the wakelock interface, does not use any handles which makes it > impossible to get reasonable stats (You don't know which pm_stay_awake > request pm_relax is reverting). Why is that a problem (out of curiosity)? > The proposed in user-space interface > of calling into every process that receives wakeup events before every > suspend call Well, you don't really need to do that. > is also not compatible with existing apps. Thanks, Rafael -- 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/ |