[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Alan Cox on 28 May 2010 05:20 > Android does not only run on phones. It is possible that no android > devices have ACPI, but I don't know that for a fact. What I do know is > that people want to run Android on x86 hardware and supporting suspend > could be very benficial. Sufficently beneficial to justify putting all this stuff all over the kernel and apps ? That is a *very* high hurdle, doubly so when those vendors who have chosen to be part of the community are shipping phones and PDAs just fine without them. > > I would imagine the existing laptops will handle power management limited > > by the functionality they have available. Just like any other piece of > > hardware. > > I think existing laptops (and desktops) can benefit from opportunistic > suspend support. If opportunistic suspend is used for auto-sleep after > inactivity instead of forced suspend, the user space suspend blocker > api will allow an application to delay this auto sleep until for > instance a download completes. This part could also be done with a This assumes you modify all the applications. That isn't going to happen. The hardware is going to catch up anyway. > alarms. I know my desktops can wakeup at a specific time by > programming an RTC alarm, but without suspend blockers how do you > ensure that the system does not suspend right after the alarm > triggered? I have a system that wakes up at specific times requested How do you know that isn't the correct behavior. My laptop behaves in that way if for example the battery is almost flat. Your suspend blocker would cause me to lose all my work with a flat battery. This is another example of why the application must not be the policy manager. In the normal case in the PC world outside of corner cases like flat batteries the answer is really simple. The laptop suspend to RAM on idle intervals set in the BIOS and the like are sufficient that progress will have been made before it considers going back to sleep again. Right now its about ten seconds in each direction plus other costs (wear on LCD backlight, disc parking etc). 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/
From: Arve Hjønnevåg on 28 May 2010 05:20 On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian(a)mickler.org> wrote: > On Thu, 27 May 2010 20:05:39 +0200 (CEST) > Thomas Gleixner <tglx(a)linutronix.de> wrote: > >> On Thu, 27 May 2010, Matthew Garrett wrote: >> >> > On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote: >> > >> > > Oh no. They paper over a short coming. If there is a pending event, >> > > the kernel knows that. It just does not make use of this >> > > information. Blockers just paper over this by sprinkling >> > > do_not_suspend() calls all over the place. What a sensible solution. >> > >> > Even if we could use suspend-via-deep-idle-state on PCs, we still need >> > to be able to enter suspend while the system isn't idle. There's two >> > ways to do that: >> > >> > 1) Force the system to be idle. Doing this race-free is difficult. >> > >> > 2) Enter suspend even though the system isn't idle. Since we can't rely >> > on the scheduler, we need drivers to know whether userspace has consumed >> > all wakeup events before allowing the transition to occur. Doing so >> > requires either in-kernel suspend blockers or something that's almost >> > identical. >> >> You're just not getting it. If user space has consumed the event is >> not relevant at all. >> >> What's relevant is whether the app has processed the event and reacted >> accordingly. That's all that matters. >> >> Emptying your input queue is just the wrong indicator. >> >> And as I explained several times now: It does _NOT_ matter when the >> app goes back in to blocked/idle state. You have to spend the CPU >> cycles and power for that anyway. >> >> And for the apps which do not use the user space blockers the queue >> empty indicator is just bullshit, because after emptying the queue the >> kernel can go into suspend w/o any guarantee that the event has been >> processed. >> >> The whole concept sucks, as it does not solve anything. Burning power >> now or in 100ms is the same thing power consumption wise. >> >> Thanks, >> >> � � � tglx > > Thomas, > do you really have a problem with the actual concept? Or do you just > don't like the way it is done? > > IMO, the whole concept is defining 2 modes of operation: > > 1. user interacts with the device (at least one suspend block active) > 2. user doesn't interact with the device (zero suspend block active) That is a somewhat odd way of looking at it. Yes we have two modes of operation, but an active suspend blocker does not mean that the user is interacting with the device. The way we use it, the "main" suspend blocker is active when the user interacts with the device (controlled by writing to /sys/power/state). All other suspend blockers are used to prevent suspend when user space has decided that the user is not interacting with the device. This includes blocking suspend in the kernel on key events which means the user actually is interacting with the device, even if user-space has not realized it yet. For other events, like an incoming phone call, we block suspend and make some noise with the hope that the user will start interacting with the device. > > In case 1. the device wants _everything_ sheduled as normal (and save > maximum possible power, i.e. runtime pm with every technology available > now). > > In case 2. we want nothing sheduled (and save maximum possible power, > i.e. suspend) > OK. > And now, every application and every kernel driver annotates (on behalve > of the user) if it (possibly) interacts with the user. > Applications that interact with the user do not normally need to block suspend. The user interacting with the device blocks suspend (just like with your desktop screen saver). Not every kernel driver needs to be annotated either, only potential wakeup events need to be annotated. > (Is this really the problematic bit, that userspace is giving > the kernel hints? Or is it that the hints are called "blocker"?) > > We can only enter mode 2, if _nothing_ (claims) to interact with the > user. > If nothing blocks suspend. The reason to block suspend does not have to be direct user interaction. > To integrate this with the current way of doing things, i gathered it > needs to be implemented as an idle-state that does the suspend()-call? > I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle. > Attributes of the idle states could be smth like this: > > c3 > � � � �cost-to-transition-to-this-state: X > � � � �powersavings-per-time: Y > � � � �expected time we stay in this state: relative short, there is a > � � � � � � � �timer sheduled > � � � �suspend-blockers: ignored > > suspend > � � � �cost-to-transition-to-this-state: depends, how much drivers to > � � � �suspend, how much processes to freeze, how much state to save > � � � �powersavings-per-time: Y > � � � �expected time we stay in this state: long, independent of > � � � � � � � �sheduled timers > � � � �suspend-blockers: must not be activated > > > Now all transitions and opportunistic suspend could be handled by the > same algorithms. > > Would this work? > I'm not sure what you mean. -- Arve Hj�nnev�g -- 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: Arve Hjønnevåg on 28 May 2010 05:40 2010/5/28 Alan Cox <alan(a)lxorguk.ukuu.org.uk>: >> Android does not only run on phones. It is possible that no android >> devices have ACPI, but I don't know that for a fact. What I do know is >> that people want to run Android on x86 hardware and supporting suspend >> could be very benficial. > > Sufficently beneficial to justify putting all this stuff all over the > kernel and apps ? That is a *very* high hurdle, doubly so when those In my opinion yes. > vendors who have chosen to be part of the community are shipping phones > and PDAs just fine without them. > >> > I would imagine the existing laptops will handle power management limited >> > by the functionality they have available. Just like any other piece of >> > hardware. >> >> I think existing laptops (and desktops) can benefit from opportunistic >> suspend support. If opportunistic suspend is used for auto-sleep after >> inactivity instead of forced suspend, the user space suspend blocker >> api will allow an application to delay this auto sleep until for >> instance a download completes. This part could also be done with a > > This assumes you modify all the applications. No it does not. You only have to modify the applications were you want to improved behavior compared to what you have now. > That isn't going to happen. > The hardware is going to catch up anyway. I want it work today. > >> alarms. I know my desktops can wakeup at a specific time by >> programming an RTC alarm, but without suspend blockers how do you >> ensure that the system does not suspend right after the alarm >> triggered? I have a system that wakes up at specific times requested > > How do you know that isn't the correct behavior. If the inactivity timeout happens to expire at the same time as my alarm that would wake up the system to run my scheduled task if it was already suspended my sceduled task will not run when scheduled. How can you argue that this is the correct behavior. > My laptop behaves in > that way if for example the battery is almost flat. Your suspend blocker > would cause me to lose all my work with a flat battery. This is another > example of why the application must not be the policy manager. > You can still force suspend when the battery gets low. > In the normal case in the PC world outside of corner cases like flat > batteries the answer is really simple. The laptop suspend to RAM > on idle intervals set in the BIOS and the like are sufficient that > progress will have been made before it considers going back to sleep > again. Right now its about ten seconds in each direction plus other costs > (wear on LCD backlight, disc parking etc). > I'm not sure what you are trying to say here. Are you saying your laptop enters S3 from idle? -- Arve Hj�nnev�g -- 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 28 May 2010 05:40 > Keep in mind, though, that a solution which is acceptable for Android > has to include making sure that crappy applications don't cause the Ted if you are speaking for Android do you think you should post from a google address or with a google .sig ? > battery to get drained. There seem to be some people who seem > adamently against this requirement. From the Android folks' > perspective, this is part of what is required to have an open app > store, as opposed to one where each application has to be carefully > screened and approved ala the Apple iPhone App Store. The other vendors appear to be managing nicely without magic blockers. I conjecture therefore there are other solutions. > We need to agree on the requirements up front, because otherwise this > is going to be a waste of everyone's time. This is why I am trying to understand the problem properly. > And if we can't get agreement on requirements, I'd suggest appealing > this whole thing to Linus. Either he'll agree to the requirements > and/or the existing implementation, in which case we can move on with The existing implementation has been comprehensively rejected by half the x86 maintainers and scheduler people to start with. That's a fairly big 'No'. > our lives, or he'll say no, in which case it will be blately obvious > that it was Linux developer community who rejected the Android > approach, despite a fairly large amount of effort trying to get > something that satisfies *all* of the various LKML developers who have Ted save the politicing and blame mongering for management meetings please. If we don't have a solution it means that between us we couldn't find a viable solution. Maybe there isn't one, maybe we missed it. It's as much 'google rejects kernel approach' as 'kernel rejects google approach' and more importantly its actually 'we (cumulative) were not smart enough between us to figure it out' > P.S. Keep in mind how this looks from an outsider's perspective; an > embedded manufacturer spends a fairly large amount of time answering > one set of review comments, and a few weeks later, more people pop up, > and make a much deeper set of complaints, and request that the current > implementation be completely thrown out and that someone new be > designed from scratch --- and the new design isn't even going to meet > all of the requirements that the embedded manufacturer thought were > necessary. Is it any wonder a number of embedded developers have > decided it's Just Too Hard to Work With the LKML? In some cases it is easier to do stuff yourself than work with others. One of the conditions of working in a public space is that you do so without harming others. This is why in much of the western world you can drive a car around your own land without a licence but must have one to drive on a public road. This is why a restuarant must meet different food standards to a home kitchen. This is why the kernel standards are higher than what you go off and do in private. Android is a very unique and extremely narrow environment. If it really is special enough to need its own kernel fork it isn't the first case for that and it's not a problem. The GPL is quite happy to encourage this. Time will then answer the questions because in 3 years time either every non Google phone will be kicking butt without suspend blockers, or every phone vendor using Linux with a traditional user space will be demanding them. 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/
From: Alan Cox on 28 May 2010 05:50
Ted As a PS to the previous email the situation has I think more choices than you portray. Given the need for various constraints imposed by drivers for things like RT it's entirely possible that a solution ends up being something like Kernel proper: Turn suspend block kernel API into an expression of constraints (or whatever else seems to work) Throw the user space in the bin Google: Use the constraints in a sledgehammer manner (hey it solves your problem in that form so why not) Patch in a private user space API That makes things much much easier as we don't risk getting a horribly broken API into the kernel that is hard to remove, while hopefully meaning its rather easier for google to merge drivers and other code as well as to maintain a smaller patch set. -- 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/ |