[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 1 Jun 2010 16:10 On Tue, 1 Jun 2010 07:05:19 -0700 mark gross <640e9920(a)gmail.com> wrote: > > Only works 1/2 the time, but I like the idea! > It fails to get the righ answer when constraints are reduced. But, this > idea is a good improvement i'll roll into the next pm_qos update! > > thanks! > > --mgross outch. shure. i had the binary block/unblock case in my mind. (where the comparitor would be just the logical &&) 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: Florian Mickler on 1 Jun 2010 16:20 On Tue, 1 Jun 2010 22:00:35 +0200 Florian Mickler <florian(a)mickler.org> wrote: > On Tue, 1 Jun 2010 07:05:19 -0700 > mark gross <640e9920(a)gmail.com> wrote: > > > > > Only works 1/2 the time, but I like the idea! > > It fails to get the righ answer when constraints are reduced. But, this > > idea is a good improvement i'll roll into the next pm_qos update! > > > > thanks! > > > > --mgross > > outch. shure. i had the binary block/unblock case in my mind. (where > the comparitor would be just the logical &&) And even there it wouldn't work in general. What about keeping the list sorted? (Or using the rbtree implementation). Well, I'm getting some sleep and tomorrow I will think about it some more. > 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: James Bottomley on 1 Jun 2010 17:10 On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: > > > You're the one mentioning x86, not me. I already explained that some > > MSM hardware (the G1 for example) has lower power consumption in S3 > > (which I'm using as an ACPI shorthand for suspend to ram) than any > > suspend from idle C state. The fact that current x86 hardware has the > > same problem may be true, but it's not entirely relevant. > > As long as you can set a wakeup timer, an S state is just a C state with > side effects. The significant one is that entering an S state stops the > process scheduler and any in-kernel timers. I don't think Google care at > all about whether suspend is entered through an explicit transition or > something hooked into cpuidle - the relevant issue is that they want to > be able to express a set of constraints that lets them control whether > or not the scheduler keeps on scheduling, and which doesn't let them > lose wakeup events in the process. Exactly, so my understanding of where we currently are is: 1. pm_qos will be updated to be able to express the android suspend blockers as interactivity constraints (exact name TBD, but probably /dev/cpu_interactivity) 2. pm_qos will be updated to be callable from atomic context 3. pm_qos will be updated to export statistics initially closely matching what suspend blockers provides (simple update of the rw interface?) After this is done, the current android suspend block patch becomes a re-expression in kernel space in terms of pm_qos, with the current userspace wakelocks being adapted by the android framework into pm_qos requirements expressed to /dev/cpu_interactivity (or whatever name is chosen). Then opportunistic suspend is either a small add-on kernel patch they have in their tree to suspend when the interactivity constraint goes to NONE, or it could be done entirely by a userspace process. Long term this could migrate to the freezer and suspend from idle approach as the various problem timers get fixed. I think the big unresolved issue is the stats extension. For android, we need just a name written along with the value, so we have something to hang the stats off ... current pm_qos userspace users just write a value, so the name would be optional. From the kernel, we probably just need an additional API that takes a stats name or NULL if none (pm_qos_add_request_named()?). Then reading the stats could be done by implementing a fops read routine on the misc device. Did I miss anything? James -- 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: David Brownell on 1 Jun 2010 17:40 --- On Tue, 6/1/10, James Bottomley <James.Bottomley(a)suse.de> wrote: > > As long as you can set a wakeup timer, an S state is just a C state with > > side effects. I've seen similar statements on this endless thread before; they're not quite true... > > The significant one is that entering an > > S state stops the process scheduler and > > any in-kernel timers. There's a structural difference too, related to peripheral device activity and power states. Specifically, peripherals can be active in C states (erforming I/O, maybe with DMA etc) and will in general not be in lowest power states (PCI etc). Whereas entry to ACPI S-states involves calling the AML code to put those peripherals into lowest power modes ... ones they can't in general enter at run time. (An additional task of that bytecode is to activate any wakeup logic, which again is not generally functional in except in S-states). The point being perhaps more that ACPI doesn't map well to the more power-efficient architectures (often built on ARM) ... hardware vendors provide all kinds of PM hooks, and Linux can choose between them so it's more power-miserly than if it tried to emulate an ACPI based platform. I've seen some Linux systems which put DRAM into self-refresh during certain idle modes, for example, not just during suspend-to-RAM, if it's known that no DMA is active. (Why not save that power if it's safe?) Likewise, disable some oscillators and PLLs if they're not needed (the clock API allows that to be done regardless of "C-states" etc). The notion of "suspend" gets introduced on such systems primarily to match the ACPI-ish models that exist ... rather than because they necessarily make good matches for the hardware. Which has left a puzzle: how and why to use such "suspend" models? Maybe that's underlying some of the pushback for the notion of automagic entry to "suspend" states. - Dave -- 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 1 Jun 2010 18:00
On Tuesday 01 June 2010, Arve Hj�nnev�g wrote: > On Mon, May 31, 2010 at 3:05 PM, Rafael J. Wysocki <rjw(a)sisk.pl> wrote: > > On Monday 31 May 2010, Neil Brown wrote: > >> On Thu, 27 May 2010 23:40:29 +0200 (CEST) > >> Thomas Gleixner <tglx(a)linutronix.de> wrote: > >> > >> > On Thu, 27 May 2010, Rafael J. Wysocki wrote: > >> > > >> > > On Thursday 27 May 2010, Thomas Gleixner wrote: > >> > > > On Thu, 27 May 2010, Alan Stern wrote: > >> > > > > >> > > > > On Thu, 27 May 2010, Felipe Balbi wrote: > >> > > > > > >> > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: > >> > > > > > >If people don't mind, here is a greatly simplified summary of the > >> > > > > > >comments and objections I have seen so far on this thread: > >> > > > > > > > >> > > > > > > The in-kernel suspend blocker implementation is okay, even > >> > > > > > > beneficial. > >> > > > > > > >> > > > > > I disagree here. I believe expressing that as QoS is much better. Let > >> > > > > > the kernel decide which power state is better as long as I can say I > >> > > > > > need 100us IRQ latency or 100ms wakeup latency. > >> > > > > > >> > > > > Does this mean you believe "echo mem >/sys/power/state" is bad and > >> > > > > should be removed? Or "echo disk >/sys/power/state"? They pay no > >> > > > > >> > > > mem should be replaced by an idle suspend to ram mechanism > >> > > > >> > > Well, what about when I want the machine to suspend _regardless_ of whether > >> > > or not it's idle at the moment? That actually happens quite often to me. :-) > >> > > >> > Fair enough. Let's agree on a non ambigous terminology then: > >> > > >> > forced: > >> > > >> > suspend which you enforce via user interaction, which > >> > also implies that you risk losing wakeups depending on > >> > the hardware properties > >> > >> Reasonable definition I think. However the current implementation doesn't > >> exactly match it. > >> With the current implementation you risk losing wakeups *independent* of the > >> hardware properties. > > > > Define "losing", please. > > > > Currently, we simply don't regard hardware signals occuring _during_ the > > suspend operation itself as wakeups (unless they are wakeup interrupts to be > > precise, because these _are_ taken into account by our current code). > > > > The reason is that the meaning of given event may be _different_ at run time > > and after the system has been suspended. For example, consider a power button > > on a PC box. If it's pressed at run time, it usually means "power off the > > system" to the kernel. After the system has been suspended, however, it means > > "wake up". So, you have to switch from one interpretation of the event to the > > other and that's not an atomic operaition (to put it lightly). > > > >> Even with ideal hardware events can be lost - by which I mean that they will > >> not be seen until some other event effects a wake-up. > >> e.g. the interrupt which signals the event happens immediately before the > >> suspend is requested (or maybe at the same time as), but the process which > >> needs to handle the event doesn't get a chance to see it before the suspend > >> procedure freezes that process, and even if it did it would have no way to > >> abort the suspend. > >> > >> So I submit that the current implementation doesn't match your description of > >> "forced", is therefore buggy, and that if it were fixed, that would be > >> sufficient to meet the immediate needs of android. > > > > I don't really think it may be fixed with respect to every possible kind of > > hardware. On platforms where I/O interrupts are wakeup events it should > > work right now. On other platforms it may be impossible to overcome hardware > > limitations. > > > > There is no reason you cannot make the rtc alarms work reliably on x86 > hardware. They usually work, but not in 100% of cases. Generally, "x86 hardware" is a broad category, where modern ones have much more interesting capabilities than the older. > Even if you may loose key events while suspending I think it > is still valuable to have reliable alarms. I don't think anyone will argue with that. :-) 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/ |