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: Florian Mickler on 5 Aug 2010 01:40 On Wed, 4 Aug 2010 16:10:03 -0700 "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > On Wed, Aug 04, 2010 at 03:56:42PM -0700, david(a)lang.hm wrote: > > On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote: > > > > >On Wed, Aug 4, 2010 at 3:31 PM, <david(a)lang.hm> wrote: > > >>On Wed, 4 Aug 2010, Matthew Garrett 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 > > >>>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 > > >>>having this conversation? :) It'd be good to have some feedback from > > >>>Google as to whether this satisfies their functional requirements. > > >> > > >>the proposal that I nade was not to use cgroups to freeze some processes and > > >>not others, but to use cgroups to decide to ignore some processes when > > >>deciding if the system is idle, stop everything or nothing. cgroups are just > > >>a way of easily grouping processes (and their children) into different > > >>groups. > > > > > >That does not avoid the dependency problem. A process may be waiting > > >on a resource that a process you ignore owns. I you ignore the process > > >that owns the resource and enter idle when it is ready to run (or > > >waiting on a timer), you are still effectively blocking the other > > >process. > > > > and if you don't have a wakelock the same thing will happen. If you > > expect the process to take a while you can set a timeout to wake up > > every 30 seconds or so and wait again, this would be enough to > > prevent you from going to sleep (or am I misunderstanding how long > > before you go into suspend without a wakelock set, see my other > > e-mail for the full question) > > The difference between the Android scheme and your proposal is that the > Android scheme freezes -all- the processes, not just a subset of them. > Therefore, in the Android scheme, the case of one process attempting to > acquire a resource held by a frozen process. In contrast, any scheme > that attempts to freeze only a subset of the processes must somehow > either avoid or properly handle the situation where a frozen process is > holding a resource that a running process is trying to acquire. > > Thanx, Paul No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle is used. For idle decision a certain subset of tasks is ignored. Where suspend is prevented by the trusted process in android-world taking a wakelock, here it would just prevent the system from going idle by arming timers. This would be pretty equivalent to the suspend-blocker scheme and not introduce new userspace api. But the downside is, as Arve pointed out, that now one can not get full-idle-power-leverage while suspend is blocked. [1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and following Cheers, Flo -- 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: Florian Mickler on 5 Aug 2010 02:00 On Thu, 5 Aug 2010 07:33:59 +0200 Florian Mickler <florian(a)mickler.org> wrote: > On Wed, 4 Aug 2010 16:10:03 -0700 > "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > > No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle > is used. For idle decision a certain subset of tasks is ignored. > > Where suspend is prevented by the trusted > process in android-world taking a wakelock, here it would just prevent > the system from going idle by arming timers. > > This would be pretty equivalent to the suspend-blocker scheme and not > introduce new userspace api. But the downside is, as Arve pointed out, > that now one can not get full-idle-power-leverage while suspend > is blocked. > > [1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and > following > > > Cheers, > Flo > There are a few downsides that got mentioned already in reponse.. I got a little lagged behind. There are upsides to this approach like not having a special purpose userspace api, conceptually integrating suspend into the idle mechanism .. Short summary of the cons that got mentioned: - applications need to resort to polling to keep the system out of idle (-> system will never be fully idle) - the race between deciding to suspend and becoming active again is not handled - no special statistics available - the timers of the ignored applications will behave unexpected (as the monotonic clock is not stopped)... while applications have already to cope with network-loss, other side effects of suspend without monotonic clock stopped are to be expected... Cheers, Flo -- 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 5 Aug 2010 09:10 On Thu, 5 Aug 2010, Florian Mickler wrote: > On Thu, 5 Aug 2010 07:33:59 +0200 > Florian Mickler <florian(a)mickler.org> wrote: > >> On Wed, 4 Aug 2010 16:10:03 -0700 >> "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > >> >> No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle >> is used. For idle decision a certain subset of tasks is ignored. >> >> Where suspend is prevented by the trusted >> process in android-world taking a wakelock, here it would just prevent >> the system from going idle by arming timers. >> >> This would be pretty equivalent to the suspend-blocker scheme and not >> introduce new userspace api. But the downside is, as Arve pointed out, >> that now one can not get full-idle-power-leverage while suspend >> is blocked. >> >> [1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and >> following >> >> >> Cheers, >> Flo >> > > There are a few downsides that got mentioned already in reponse.. I got > a little lagged behind. > > There are upsides to this approach like not > having a special purpose userspace api, conceptually integrating > suspend into the idle mechanism .. first off, a good summary of that I've been saying, thanks. > Short summary of the cons that got mentioned: > > - applications need to resort to polling to keep the system > out of idle (-> system will never be fully idle) true, although the power difference between a system that is completelyidle (but with a wavelock held) and a system where one application is polling every 10 seconds or so is _really_ low. > - the race between deciding to suspend and becoming active > again is not handled this one I will admit to not fully understanding, it sounds like there are opptions here, but I don't understand them or their trade-offs > - no special statistics available or no special statistics needed. Powertop is already avaible to analyse a system and report what processes are keeping it awake. Why would this not be enough? > - the timers of the ignored applications will behave unexpected > (as the monotonic clock is not stopped)... while applications > have already to cope with network-loss, other side effects of > suspend without monotonic clock stopped are to be expected... I'm not sure this is true. there's nothing stopping the suspend (when it finally does happen) from stopping the monotonic clock. The core of my proposal is tweaking how we decide to suspend. Other than the possibility that we decide to suspend between timers (and set an alarm to wake up when a timer would go off) I'm not suggesting that the suspend itself change once it's finally triggered. 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: david on 5 Aug 2010 09:30 On Thu, 5 Aug 2010, Rafael J. Wysocki wrote: > 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). This race sounds like it's generic across all platforms and not an Android specific problem. Android is just more sensitive to it as they do a suspend more frequently. one thought on this, as a generic solution to the problem would it be possible for the suspend controller (whatever it is) to do the following 1. decide to suspend 2. setup monitors for the wake events 3. double check if it still wants to suspend this way you don't pay the overhead of the wake monitors while you are running normally, but if one hits while you are suspending you wake up again as quickly as you can (which could involve aborting the suspend and backing out, or going fully into suspend and waking up immediatly, depending on which is better/easier at the time you get the wakeup) 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 5 Aug 2010 09:40
On Wed, Aug 04, 2010 at 03:20:04PM -0700, david(a)lang.hm wrote: > on the other hand, making an application avoid consuming inappropriate > background resources helps everywhere. an explicit "don't let the machine > sleep" only works if you are trusted by a system that implements this > flag. > > yes, it is painful to make the change, but the end result is better (and > there are more tools out there to figure things out) Nobody's denying that it's better, but people are saying they want to design a platform that's capable of handling the software we have rather than the software we'd like to have. > but if you have an application in the mid-level trust situation, go ahead > and have it talk to a 'keepalive' daemon that is in the 'trusted' set and > let the rest of the app run untrusted. As I noted elsewhere, the > keepalive daemon would need very little in the way of resources and can > implement much more complex policies than anyone is going to be willing > to put in the kernel. That doesn't work. You'll race with wakeup events. > similar to the current implementation, the arrival of a packet could be > counted as activity that keeps the system awake for a bit (your timeout) How? You're either polling in order to know whether there's network activity, or you're having every network packet wake up the policy daemon, or you've got something that looks like the kernel side of wakelocks. >> Cell networks typically have no background traffic, for obvious reasons. > > but don't most new smartphones also connect up to wifi networks? those > are FAR from quiet. Wifi radio typically dwarfs your other power consumption anyway. The typical situation is one where you're not attached to a wifi network. > I'm not suggesting running all events through some central server (unless > you count the kernel as that server), I'm saying that the decision that > the system is idle and therefor can be stopped should be able to take > this infomation into account, and if there's a race here, it should be a > race that exists everywhere else, so there should be a general solution, > not something specific to one use-case. (and definantly not something > that requires all software to be modified and trusted to implement) You're right. It's a race that exists everywhere else, and it's inherent unless you have some handshaking between userspace and the kernel when entering suspend. Which is what wakelocks provide. Nobody has proposed a solution that works without modifying existing code. -- 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/ |