[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 26 May 2010 11:40 > I'm not saying that your argument is not valid. But why don't you look > at suspend blockers as a contract between userspace and kernelspace? An > Opt-In to the current guarantees the kernel provides in the non-suspend > case. It is a contract - but not the right one. You are removing autonomy from the kernel when only the kernel can measure the full picture and when the kernel is actually supposed to be responsible for resource management. > On the other hand, applications can say, they don't need that much > power and userspace guaranties and not take a suspend blocker. Even the the model is wrong. > I don't think opportunistic suspend is a policy decision by the kernel. > it is something new. Something which currently only the android Disagree. It's an arbitary and misleading divide that happens to reflect a specific vendors current phones. Worse yet it may not reflect their own future products. It assumes for example that their is some power level that is 'suspend' that is singular, application understood and can be effectively user space managed. Big assumptions and not ones that seem to be sensible. It also breaks another rule - when the hardware changes your application blocker policies will be wrong. Do you want multiple hand optimised copies of each app ? Take a look at what happened to CPU designs where the assumption was you'd recompile the app for each CPU version to get any useful performance. If you are instead expressing it as "must be able to respond in time X" and "must be able to wake up from an event on an active device" then your interface is generic and hardware independant. If "bouncing cows" says 'need to wake up every 0.3 seconds" you want the kernel to decide how best to do that. It will vary by hardware. On todays desktop PC thats probably a low power state limit. On some current embedded hardware it might be a special deep sleep mode. On one or two devices it might be 'suspend'. It might also be that the properties have been set to 2 seconds already so it gets told it can't have 0.3. The app cannot be allowed to know platform specific stuff or your portability comes apart and you end up with a disaster area where each app only comes on a subset of devices. Express the requirement right and you get a simple clean interface that continues to work. Express it wrong and you get a mess. > userspace implements / supports. If you don't want to suspend while > looking at the bouncing-cow, you have to take a suspend blocker and > make yourself a user-visible power-eater, or don't do Thats a very big hammer and it doesn't express what I actually want, which is to allow the cows to run as efficiently as possible. > > echo "opportunistic" > /sys/power/policy > > in the first place. But you can do this properly by having a per process idle requirement, and that can encompass things like hard real time as well (or even gaming). The suspend blockers break all the global policy, don't solve real time and don't allow for sensible expansion models. They don't solve our existing wakeup versus device problems either. > How does this address the loss of wakeup events while using suspend? > (For example the 2 issues formulated by Alan Stern in [1]) In this environment the problem cannot occur in the first place unless there are kernel code bugs, if there are then they are in GPL code and can be fixed. But you are mixing up interfaces and implementations which I find is usually a bad idea. Doing the right thing badly gives you an interface to an implementation you can later fix. Doing the wrong thing well leaves you stuck down a hole. > p.s.: > dmk(a)schatten /usr/src/linux $ grep -r "setpidle" . Yes I know - no point having a new function which has an in use name is there ? It's trivial to add per process idling or wakeup requirements. 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: Florian Mickler on 26 May 2010 11:50 On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: > > I'm not saying that your argument is not valid. But why don't you look > > at suspend blockers as a contract between userspace and kernelspace? An > > Opt-In to the current guarantees the kernel provides in the non-suspend > > case. > > That's backwards. I think that's the point of it. -- 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 11:50 On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: > On Wed, 26 May 2010 17:15:47 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: > > > I'm not saying that your argument is not valid. But why don't you look > > > at suspend blockers as a contract between userspace and kernelspace? An > > > Opt-In to the current guarantees the kernel provides in the non-suspend > > > case. > > > > That's backwards. > > I think that's the point of it. Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again. -- 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 12:00 On Wed, 26 May 2010 17:47:35 +0200 Florian Mickler <florian(a)mickler.org> wrote: > On Wed, 26 May 2010 17:45:00 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote: > > > On Wed, 26 May 2010 17:15:47 +0200 > > > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > > > > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote: > > > > > I'm not saying that your argument is not valid. But why don't you look > > > > > at suspend blockers as a contract between userspace and kernelspace? An > > > > > Opt-In to the current guarantees the kernel provides in the non-suspend > > > > > case. > > > > > > > > That's backwards. > > > > > > I think that's the point of it. > > > > Apparently, and you're not accepting that we're telling you we think its > > a singularly bad idea. Alan seems to have the skill to clearly explain > > why, I suggest you re-read his emails again. > > I'm sorry if I offend you. I indeed read Alan's emails. It's just they > have more content than yours. So it takes longer. > > Cheers, > Flo p.s.: also they encourage me to think more before answering. -- 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: Thomas Gleixner on 26 May 2010 13:30
Florian, On Wed, 26 May 2010, Florian Mickler wrote: > > On the other hand, applications can say, they don't need that much > power and userspace guaranties and not take a suspend blocker. > > This is an option which they currently don't have. Wrong. A well coded power aware application is very well able to express that in various ways already today. Admittedly it's far from perfect, but that can be fixed by adding interfaces which allow the power aware coder to express the requirements of his application actively, not by avoiding it. suspend blockers are completely backwards as they basically disable the kernels ability to do resource management. Also they enforce a black and white scheme (suspend or run) on the kernel which is stupid, as there are more options to efficiently save power than those two. While current android devices might not provide them, later hardware will have it and any atom based device has them already. So what the kernel needs to know to make better decisions are things like: - how much slack can timers have (exisiting interface) - how much delay of wakeups is tolerated (missing interface) and probably some others. That information would allow the kernel to make better decisions versus power states, grouping timers, race to idle and other things which influence the power consumption based on the hardware you are running on. > I don't think opportunistic suspend is a policy decision by the kernel. > it is something new. Something which currently only the android > userspace implements / supports. If you don't want to suspend while > looking at the bouncing-cow, you have to take a suspend blocker and > make yourself a user-visible power-eater, or don't do > > echo "opportunistic" > /sys/power/policy > > in the first place. > > This "optionally being badly written, who cares?" is a new feature the > kernel can provide to applications. It's a misfeature which the kernel should not provide at all. It sends out the completely wrong message: Hey, we can deal with your crappy code, keep on coding that way. While this seems to sound cool to certain people in the mobile space, it's completely backwards and will backfire in no time. The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users. Thanks, tglx -- 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/ |