On Thursday 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote: > > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote: > > > > we still need to be able to enter suspend while the system isn't idle. > > > > > > _WHY_!? > > > > Because if I'm running a kernel build in a tmpfs and I hit the sleep > > key, I need to go to sleep. Blocking processes on driver access isn't > > sufficient. > > But that's a whole different issue. I agree that a forced suspend for > things like that make sense, just not for power managing a running > system. PC style hardware like that doesn't wake up from suspend for > funny things like a keypress either (good thing too). In fact one of my PC test boxes does that. :-) > Anyway all that already works (more or less), so I don't see the > problem. The whole idea behind the patchset is not to power manage a _running_ system. It is based on the observation that for a good deal of time one doesn't need the system to be running at all, which is quite pragmatic to me. Given that, the point is to figure out when the system doesn't need to run and effectively shut it down at that point (memory is refreshed in that state so that the system can go back to the working state relatively quickly). From there, the system can only be woken up by specific events (like pressing a power button). However, it would be wasteful to shut it down knowing that the condition used to make the decision to shut it down didn't hold any more. The current mainline relies on the user to make that decision (and write something to /sys/power/state), but in principle I don't see why it cannot be made by software (either the kernel or the user space, or both in combination). The question is how to "teach" the software to make that decision in a way that's acceptable to the user and the Arve's approach is an attempt to give an answer to it. Of course, you may not like it, but the truth is it works in practice reasonably well. That may not be an argument for merging it, but then we should at least tell the Android people what's fundamentally wrong with it and how to do it in a different way so that their own requirements are met. As long as we don't do that, we're rejecting it just because we don't like it. Yes, Alan Cox said why he thought the approach was fundamentally wrong from the technical standpoint and I appreciate that. I don't think, though, that we can give Google a serious advice how to achieve their goal (which is battery life comparable to what they get with suspend blockers) in any different way. The approach with user space power manager suggested by Dmitry and Alan Stern may work, but it still assumes some kind of suspend blockers to be present in the kernel. If we reject that too, I wonder what approach Google is supposed to use and still get the same battery life they get with suspend blockers. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
