[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: Florian Mickler on 29 May 2010 07:20 On Sat, 29 May 2010 12:42:37 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote: > > On Sat, 29 May 2010 00:11:32 +0200 > > "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > > > > > > > Having reconsidered the suspend blockers idea I came to the conclusion that > > > in fact it was a workaround for three different problems. > > > > But it is also a change of paradigm. The scheduler should strive to > > have the system idle as long as possible to conserve battery. And > > everything that does not serve the purpose of the device has to be > > considered as not worth running, except if there are other > > purpose-fullfilling tasks to run anyway. > > No the purpose of the scheduler is to run tasks when they are runnable. > Not to second guess whatever caused them to become runnable. > > If you start to randomly not run tasks, the inversion chaos that ensues > is terrible. You can apply the regular means of alleviating that and > that entails adding *-inheritance to all blockable resources. The -rt > patch set is doing that in part. Yes. In the scheduler it becomes a hard problem. But if you have a clear definition of "purpose" (I mean, after all it is a phone) and you can annotate this in a way that makes sense. (Suspend blockers?) Then stopping the scheduler and suspend the device is at least an easily understandable, maybe naive, approach. > > You really need to make applications not want to run and block on their > own volition (in a resource free point) and otherwise make them block on > something forcefully and disregard any malfunctioning that would result > from that, and in extreme cases terminate (releasing all resources). I can see why this would be the best solution. But it would also be just dodging the problem, wouldn't it? > But really Android shouldn't even need kernel support to do all this, > since its hosted on this massive middle-ware that intercepts everything, > called a Java Virtual Machine. Here also, dodging the problem. Maybe there is no good solution for this. And maybe it even is not a generic problem. Suspend blockers block suspend. So that is what they do. And they have a userspace API (which of course has to be acceptable and not be borken). And they are optional. But having a way in the drivers to annotate some kind of constraints seems to be a worthwile change in all cases. So this at least should go in. And while there are differing opinions about the android approach (feature vs misfeature) of suspending all the time, i think this is addressed by having them configurable. Also the fear that userspace becomes infected with platform knowledge is, in my eyes, only a secondary problem, because it is confined to the android framework. The android framework guarantess applications that they run as long as the user interacts with the device. Applications have to deal with suspend in every case. So no special knowledge needs to be there. > Now, all I'm interested in is providing interfaces from the kernel where > needed, so that userspace can be optimally frugal with power usage, and > can monitor/contain badly behaving tasks. > I think this is a sensible approach. 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: Alan Stern on 29 May 2010 10:20 On Sat, 29 May 2010, Peter Zijlstra wrote: > Correct, I strongly oppose using suspend. Not running runnable tasks is > not a sane solution. > > If current hardware can't cope, too friggin bad, get better hardware. Taken out of context, this statement suggests you believe that x86-based laptops should not be allowed to suspend automatically when their lids are closed, and that everybody should replace their x86-based laptops with something better. Is that really what you mean? 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 Stern on 29 May 2010 10:20 On Sat, 29 May 2010, Florian Mickler wrote: > On Sat, 29 May 2010 12:42:37 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > Now, all I'm interested in is providing interfaces from the kernel where > > needed, so that userspace can be optimally frugal with power usage, and > > can monitor/contain badly behaving tasks. > > > > I think this is a sensible approach. Here is an attempt to satisfy everyone as much as possible. But first an explicit disclaimer: When I say "suspend", I mean it as in "suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode. In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend. The Android people want debugging and accountability. So in the most objectionable part of this proposal, we add a new way of registering QoS constraints: monitored constraints. The "monitored" implies that: The constraint has a name, which can be used for debugging and accounting; The kernel maintains statistics on the constraint's use and makes them available to userspace; and The PM core is notified whenever the number of active monitored constraints drops to 0. There is no /sys/power/policy file. In place of opportunistic suspend, we have "QoS-based suspend". This is initiated by userspace writing "qos" to /sys/power/state, and it is very much like suspend-to-RAM. However a QoS-based suspend fails immediately if there are any active normal QoS constraints incompatible with system suspend, in other words, any constraints requiring a throughput > 0 or an interrupt latency shorter than the time required for a suspend-to-RAM/resume cycle. If no such constraints are active, the QoS-based suspend blocks in an interruptible wait until the number of active QOS_EVENTUALLY constraints drops to 0. When that happens, it carries out a normal suspend-to-RAM -- except that it checks along the way to make sure that no new QoS constraints are activated while the suspend is in progress. If they are, the PM core backs out and fails the QoS-based suspend. Userspace suspend blockers don't exist at all, as far as the kernel is concerned. In their place, the Android runs a power-manager program that receives IPC requests from other processes when they need to prevent the system from suspending or allow it to suspend. The power manager's main loop looks like this: for (;;) { while (any IPC requests remain) handle them; if (any processes need to prevent suspend) sleep; else write "qos" to /sys/power/state; } The idea is that receipt of a new IPC request will cause a signal to be sent, interrupting the sleep or the "qos" write. There remains a question as to which kernel drivers should create monitored QOS_EVENTUALLY constraints. Perhaps userspace could be allowed to specify this (I don't know how). In any case, this is a relatively minor point. The advantages of this scheme are that this does everything the Android people need, and it does it in a way that's entirely compatible with pure QoS/cpuidle-based power management. It even starts along the path of making suspend-to-RAM just another kind of dynamic power state. If people such as Peter still want to complain that using suspend-to-RAM in Android phones isn't a good way to do power management, that's okay -- it's the designers' decision to program their phones the way they want. At least the kernel can give them the ability to do so in a way that doesn't compromise everybody else. 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: Brian Swetland on 29 May 2010 10:40 On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > > Here is an attempt to satisfy everyone as much as possible. But first > an explicit disclaimer: When I say "suspend", I mean it as in > "suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode. > > In place of in-kernel suspend blockers, there will be a new type of QoS > constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, > compatible with all cpuidle modes in which runnable threads are allowed > to run (which is all of them), but not compatible with suspend. > > The Android people want debugging and accountability. So in the most > objectionable part of this proposal, we add a new way of registering > QoS constraints: monitored constraints. The "monitored" implies that: > > The constraint has a name, which can be used for debugging > and accounting; > > The kernel maintains statistics on the constraint's use and > makes them available to userspace; and The name/statistics could obviously be gated by CONFIG_QOS_STATS or the like -- we'd want such a thing in our world and others may want to enable it to debug other situations, but the default could easily remain "no overhead". > > The PM core is notified whenever the number of active monitored > constraints drops to 0. > > There is no /sys/power/policy file. In place of opportunistic suspend, > we have "QoS-based suspend". This is initiated by userspace writing > "qos" to /sys/power/state, and it is very much like suspend-to-RAM. > However a QoS-based suspend fails immediately if there are any active > normal QoS constraints incompatible with system suspend, in other > words, any constraints requiring a throughput > 0 or an interrupt > latency shorter than the time required for a suspend-to-RAM/resume > cycle. > > If no such constraints are active, the QoS-based suspend blocks in an > interruptible wait until the number of active QOS_EVENTUALLY > constraints drops to 0. When that happens, it carries out a normal > suspend-to-RAM -- except that it checks along the way to make sure that > no new QoS constraints are activated while the suspend is in progress. > If they are, the PM core backs out and fails the QoS-based suspend. > > Userspace suspend blockers don't exist at all, as far as the kernel is > concerned. In their place, the Android runs a power-manager program > that receives IPC requests from other processes when they need to > prevent the system from suspending or allow it to suspend. The power > manager's main loop looks like this: > > for (;;) { > while (any IPC requests remain) > handle them; > if (any processes need to prevent suspend) > sleep; > else > write "qos" to /sys/power/state; > } The issue with this approach is that if userspace wants to suspend while a driver is holding a QOS_EVENTUALLY constraint, it's basically going to spin constantly writing "qos" and failing. Could we have write(powerstate_fd, "qos",3) block until all QOS_EVENTUALLY constraints are lifted or the system successfully suspends and resumes or a signal arrives? > The idea is that receipt of a new IPC request will cause a signal to be > sent, interrupting the sleep or the "qos" write. Alternatively (to ipc), we could have a driver provide the same suspendblock style interface to userspace and maps it to qos constraints. If it's something we maintain out-of-tree, no worries. The kernel side api is the bit that's the headache to maintain multiple versions of drivers with and without, after all. > There remains a question as to which kernel drivers should create > monitored QOS_EVENTUALLY constraints. Perhaps userspace could be > allowed to specify this (I don't know how). In any case, this is a > relatively minor point. > > The advantages of this scheme are that this does everything the Android > people need, and it does it in a way that's entirely compatible with > pure QoS/cpuidle-based power management. It even starts along the path > of making suspend-to-RAM just another kind of dynamic power state. > > If people such as Peter still want to complain that using > suspend-to-RAM in Android phones isn't a good way to do power > management, that's okay -- it's the designers' decision to program > their phones the way they want. At least the kernel can give them the > ability to do so in a way that doesn't compromise everybody else. I'm sure Arve will weigh in on this later, but from what I can see it certainly seems like this model provides us with the functionality we're looking for, provided the issue with spinning-while-waiting-for-drivers-to-release-constraints is sorted out. Brian -- 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 29 May 2010 11:10
> Could we have write(powerstate_fd, "qos",3) block until all > QOS_EVENTUALLY constraints are lifted or the system successfully > suspends and resumes or a signal arrives? Yes - and you can then use alarm() or similar to do timeouts (or write the timeout to the fd ?) -- 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/ |