[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 27 May 2010 18:50 On Thu, 27 May 2010 23:36:05 +0100 Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote: > > On Thu, 27 May 2010 23:09:49 +0100 > > Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > > > > > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: > > > > > > > This is I believe robust (and has been implemented on some non x86 > > > > boxes). It depends on not forcing running tasks into suspend. That is the > > > > key. > > > > > > We've already established that ACPI systems require us to force running > > > tasks into suspend. How do we avoid the race in that situation? > > > > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID > > x86 devices do not have ACPI. > > It doesn't matter. Right now there's a race condition in terms of > wakeup events on ACPI systems. What's your proposal for fixing that? I see it as a different problem - and one that seems to be minimally pressing to most users jduging by the amount of noise it hasn't caused in the past seven odd years. This started because the Android people came to a meeting that was put together of various folks to try and sort of the big blockage in getting Android and Linux kernels back towards merging. I am interested right now in finding a general solution to the Android case and the fact it looks very similar to the VM, hard RT, gamer and other related problems although we seem to have diverged from that logic. I dont think it particularly useful to go off on a mostly unrelated wild goose chase into ACPI land, especially one based on a premise of changing all the apps when the hardware will end up fixed faster. 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: Rafael J. Wysocki on 27 May 2010 18:50 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-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 Stern on 27 May 2010 19:10 Matthew: Remind me why the idle/QOS power management approach won't work here. If the difficulty is untrusted apps preventing the system from being idle, why not assign them to QoS(NONE) as Thomas suggested? If the difficulty is that some untrusted apps need to receive wakeup events, why not just decree that this is not allowed? It seems reasonable that if you can't trust a program then you shouldn't allow it to wake up the system. If the difficulty is that some trusted apps need to do CPU-burning things like drawing bouncing cows in the background, why not break these apps into two processes or threads? One can be trusted and receive all the wakeup events, and the other can be untrusted and draw all the cows it likes. We're only talking about trusted apps, most of which would be controlled by Google, so the conversion shouldn't be too hard. If the difficulty is that ACPI-based systems can't use idle/QOS PM effectively... well, so be it. We don't have to solve every problem in the world right away, and just now we're mainly concerned about helping the Android people. Alan Stern -- 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 27 May 2010 19:10 > 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. I'm getting less convinced it needs suspend blockers at all for this case, assuming that you are willing to have a policy that is based on - assuming apps play nicely - having the information to user space you need (who woke us, who blocked us, events) - dealing with offenders primarily from user space using that information I'm fairly happy about the following so far - we should have a common interface for seeing some pm events (like duh ?) but it does need careful thought so the watcher doesn't change the behaviour and break it. (Message "We are suspending", gosh someone is running to receive the message, resume being the obvious case) - Suspend is (for many platforms) just a cotinuation down the power chain. Demonstrated and implemented on ARM. Very much the direction of S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and made to work, and by reading the Moorestown PR. - Given a non forced (that is 'idle down') transition to a suspend level we can implement a 'suspend as idle' on many embedded platforms in a manner which is not racy at kernel level. Apparently implemented already on ARM - Given a non forced transition to such a suspend level and the reporting of certain events we can do a full user space managed graphical UI type environment policy in a race free fashion - With notification of who caused a resume and maybe a bit of other general stat gathering it is possible to identify and handle abuses of power resource. Proved by the fact we can do this with powertop but more elegance in the interfaces would be nice. I am not sure if a pm event is what is needed for this or a sum 'hardware triggered wake up' event. I accept that current ACPI based laptops probably couldn't make use of such a feature but I don't think this is important at the moment. A resource constraint model might help further in the ACPI case. It's useful for other stuff but it might well be a distraction and implementation detail in terms of the basic question about what is needed for something like Android. At this point the input of the Android team and the Nokia people would be rather more useful to me. 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: Rafael J. Wysocki on 27 May 2010 19:30
On Thursday 27 May 2010, Alan Stern wrote: > On Thu, 27 May 2010, Alan Cox wrote: > > > > Rather than continue going around in circles, let's agree that what the > > > Android people want is a new version of forced suspend -- not a > > > > I don't think this is true. I think that is the root of the problem. > > Of course it's true. Just ask Arve -- he wants opportunistic suspend > and it _is_ a variant of forced suspend. Ergo he wants a new type of > forced suspend. Well, as I just wrote in a different message, what he _really_ wants is to get maximum possible battery life and he found experimentally that this is achieved by suspending the whole system as often as reasonably possible. Of course, the "reasonably possible" part needs clarification. > Maybe that's not what he _ought_ to want. Nevertheless, there are > valid reasons for wanting it. > > > I don't disagree with the user experience they are trying to create or > > the fact something is needed to make it possible (if it turns out we > > can't already do it). > > > > Forced suspend is sticking stuff in running state into suspend > > > > Power management models (such as Thomas ARM box) which we know work are > > 'when nothing is running' into suspend. > > > > So for me the real question on that side of this specific case is 'how > > do you make sure those tasks are idle when you need them to be' > > > > QoS ? > > Spanking them from user space ? > > Drivers enforcing policy elements by blocking tasks ? > > Currently we use the freezer. But it is a blunt tool -- it freezes > every user process. Also, it doesn't actually make processes > unrunnable; it just arranges things so that when they do run, they > immediately put themselves back to sleep. > > And the forced-suspend design relies on the fact that processes remain > frozen throughout. If we leave some processes unfrozen and one of them > somehow becomes runnable, that means we have to abort the forced > suspend before the process is allowed to run. We could avoid that if drivers could block tasks, but there are questions to answer. First off, how a driver is supposed to know when to block the task using it and when to do its power management transparently for the task? Second, how to intercept and block all possible interfaces that user space can use to talk to drivers (how to intercept a task using mmapped device, for example)? Rafael -- 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/ |