[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: Igor Stoppa on 28 May 2010 08:10 ext Matthew Garrett wrote: > On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote: > > >> The other vendors appear to be managing nicely without magic blockers. I >> conjecture therefore there are other solutions. >> > > Actually, no. A badly behaved application will kill the N900's battery > life. Nobody else has "managed nicely" - they've just made life harder > for application developers and users, which may have something to do > with the relative levels of market adoption of Maemo and Android. I'm > not aware of any form of resource management framework in MeeGo either, > so as far as I know it'll have exactly the same problem. > > It's true that a braindead app can kill the battery. However we provide a version of powertop that is tailored to the N900, there is a nokia energy profiler meant to give graphical representation of the battery current, there is htop available and you can even get the processor activity visualized on the leftmost and rightmost keyboard backlight LEDS, when in RD mode and with screen blanked. I would advice you to not start debating on company strategies, this is not the right place. Otherwise I'll have to ask what's the expected threshold of devices sold with broken sw design to get automatic admission into the mainline kernel source tree. But this is not the direction we want to take. Notice also that we _do_ have a store and official repository where apps are monitored for sanity, also with feedback from users and their help to promote new apps to trusted state. Former Maemo 6, now MeeGo do introduce resource management from security POV, but that will also have the side effect of discriminating between signers. igor -- 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 28 May 2010 08:10 On Fri, 28 May 2010 04:35:34 -0700 Arve Hj�nnev�g <arve(a)android.com> wrote: > 2010/5/28 Florian Mickler <florian(a)mickler.org>: > > It sounds like it could save some duplication of effort to integrate > > suspend into the idle-framework. "Purpose-fulness" could be just > > another measure of "idle". > > > > To me idle means that no threads are ready to run and no interrupts are pending. I misused the term "idle". I tried to express this by "quoting" it. > > I don't think we can plug suspend in as a cpu idle state. 1. we want > to suspend even the cpu is not idle. 2. starting suspend will cause > the cpu to not be idle. > yeah. it would have to move out of the cpu-specific context. it would be a more general "system-state" thing. if the properties of the state's are well expressed, it does not matter that starting suspend will cause the cpu to not be idle, because our target-state(suspend) has better properties than any other state. (or maybe there needs to be a "state-transition-in-flight" flag.) if we take the "approximated duration of staying in that state" into account, we could provoke the pm-framework to always suspend if no constraint(i.e. blocker) is there. But really. I think I can't implement something like that. Also I really have _no_ idea how much work this would be. _And_ I am not really shure if this is a better approach than the current solution. Just an idea. 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: Theodore Tso on 28 May 2010 08:20 On May 28, 2010, at 5:37 AM, Alan Cox wrote: >> 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 ? We're all engineers here. Nobody speaks for the company as a whole without the permission of corporate PR, and that's true for Intel, IBM, and all other companies. >> 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. I've seen very hard to debug situations with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off. And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication. If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier. > 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' Maybe. And perhaps the right solution in that case is to merge both, as opposed to "consign one to the outer darkness". And I think that's a decision Linus should make. I do hope we can come up with a better solution, eventually. But I do want to point out as a process point of view, we do have other alternates other than "spinning endlessly". -- Ted -- 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 08:20 Ok lets try and produce something more concrete. The control groups may be the wrong tool but we've got several such tools already Kernel involved ---------------- acquire: mark myself important (into cgroup important) acquire(timeout) ditto, plus app timer/timeout handler release: mark myself unimportant (into cgroup downtrodden) All user -------- isHeld: app implementation internal setReferenceCounted: app implementation internal In the idle manager [Androids own probably] if (member of ignored cgroup && in user space) ignore for idle purposes In the Android code managing this [Android specific bits of probably userspace] mark downtrodden as ignored mark downtrodden as not ignored [Total kernel changes Ability to mark/unmark a scheduler control group as outside of some parts of idle consideration. Generically useful and localised. Group latency will do most jobs fine (Zygo is correct it can't solve his backup case elegantly I think) Test in the idling logic to distinguish the case and only needed for a single Android specific power module. Generically useful and localised] So I put my phone down The UI manager gets told the phone is 'down' Ten seconds later it is still down It marks the downtrodden group as 'ignored' The idle logic goes Nothing to run powersave Still nothing Ooh 0.3 seconds of nothing Drop into suspend state If I push the button we get an IRQ We come out of power save The app gets poked The app may be unimportant but the IRQ means we have a new timeout of some form to run down to idle The app marks itself important The app stays awake for 60 seconds rsyncing your email The app marks itself unimportant Time elapses We return to suspend If you are absolutely utterly paranoid about it you need the button driver to mark the task it wakes back as important rather than rely on time for response like everyone else. That specific bit is uggglly but worst case its just a google private patch to a few drivers. I understand why Android wants it. The narrower the gap between 'we are doing nothing, sit in lowest CPU on state' and 'we are off' the better the battery life and the more hittable the condition. Apart from that optional paranoia case my kernel now contains some trivial changes of generic value that have nothing to do with suspend blocking. Android has suspend blocking by choosing to use the generic features in its own specific way and we need almost no code writing ? 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: Igor Stoppa on 28 May 2010 08:30
ext Theodore Tso wrote: > I've seen very hard to debug situations with Maemo where users are essentially asked to uninstall all their applications, and then install them back one at a time, waiting several hours between each install for a charge/discharge cycle, to figure out which application was waking up the system so !@#@! much while the screen was turned off. And, when the periodic wakeups are faster than the refresh time of powertop, no, powertop won't help you find the crapplication. If you think that's acceptable, fine --- we'll see who wins in the marketplace, and who gets blamed for producing a crappy platform --- the incompetent application programmer, or the platform supplier. > Those apps were from an experimental repository, which is not enabled by default in stock SW. Of course tools can be improved, but if someone decides to run sw which is clearly under heavy development, i see little point in complaining that it might not work as expected. igor -- 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/ |