[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: Felipe Balbi on 26 May 2010 08:40 hi, On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: >And if you have two kernels, one with which your device is dead after 1 >hour and one with which your device is dead after 10 hours. Which would >you prefer? I mean really... this is ridiculous. What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases. You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app. -- balbi DefectiveByDesign.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/
From: Florian Mickler on 26 May 2010 08:40 On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi <felipe.balbi(a)nokia.com> wrote: > hi, > > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: > >And if you have two kernels, one with which your device is dead after 1 > >hour and one with which your device is dead after 10 hours. Which would > >you prefer? I mean really... this is ridiculous. > > What I find ridiculous is the assumption that kernel should provide good > power management even for badly written applications. They should work, > of course, but there's no assumption that the kernel should cope with > those applications and provide good battery usage on those cases. > > You can install and run anything on the device, and they will work as > they should (they will be scheduled and will be processed) but you can't > expect the kernel to prevent that application from waking up the CPU > every 10 ms simply because someone didn't think straight while writting > the app. > But then someone at the user side has to know what he is doing. I fear, if you target mass market without central distribution channels, you can not assume that much. 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: Peter Zijlstra on 26 May 2010 08:50 On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote: > On Wed, 26 May 2010 15:29:32 +0300 > Felipe Balbi <felipe.balbi(a)nokia.com> wrote: > > > hi, > > > > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote: > > >And if you have two kernels, one with which your device is dead after 1 > > >hour and one with which your device is dead after 10 hours. Which would > > >you prefer? I mean really... this is ridiculous. > > > > What I find ridiculous is the assumption that kernel should provide good > > power management even for badly written applications. They should work, > > of course, but there's no assumption that the kernel should cope with > > those applications and provide good battery usage on those cases. > > > > You can install and run anything on the device, and they will work as > > they should (they will be scheduled and will be processed) but you can't > > expect the kernel to prevent that application from waking up the CPU > > every 10 ms simply because someone didn't think straight while writting > > the app. > > > > But then someone at the user side has to know what he is doing. > > I fear, if you target mass market without central distribution > channels, you can not assume that much. Provide the developers and users with tools. Notify the users that their phone is using power at an unadvised rate due to proglet $foo. Also, if you can integrate into the development environment and provide developers instant feedback on suckage of their app they can react and fix before letting users run into the issue. -- 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: Vitaly Wool on 26 May 2010 09:00 On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian(a)mickler.org> wrote: > Really, what are you getting at? Do you deny that there are programs, > that prevent a device from sleeping? (Just think of the bouncing > cows app) > > And if you have two kernels, one with which your device is dead after 1 > hour and one with which your device is dead after 10 hours. Which would > you prefer? I mean really... this is ridiculous. You almost always need to "hack" the mainline software for a production system. So do it here as well. Make sure the hack is well isolated and local. You can even submit it to the mainline, better as a configuration option, _unless_ it is a *framework* that provokes writing code in an ugly and unsafe way. ~Vitaly -- 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 26 May 2010 09:00
On Wed, 26 May 2010 15:35:32 +0300 Felipe Balbi <felipe.balbi(a)nokia.com> wrote: > Hi, > > On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote: > >But then someone at the user side has to know what he is doing. > > > >I fear, if you target mass market without central distribution > >channels, you can not assume that much. > > and that's enough to push hacks into the kernel ? I don't think so. Do > it like apple and prevent multi-tasking for any non-apple applications > :-p > :) It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before. All points about the impact on the kernel have already been raised. So you should be happy there. Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not. Also I expect there to be synergies between android development and mainline kernel development _only_ if android development can use mainline kernel. And as for the quality of the "hack": I think you find this ugly, just because you don't like the concept of degrading user space guaranties on timers and stuff. But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource "power". If a user space program needs the "traditional" guaranties for functioning properly, it needs to take a suspend blocker. But _THEN_ it better be well behaved. This is a kind of contract between userspace and kernelspace. On the other hand, if I don't need these traditional guaranties on timers and stuff, I don't have to know device specific things about power consumption. I can just use whatever facilities the programming language provides without needing to worry about low level details. This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like). 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/ |