[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: Magnus Damm on 13 May 2010 23:30 On Fri, May 14, 2010 at 6:47 AM, Tony Lindgren <tony(a)atomide.com> wrote: > * Alan Stern <stern(a)rowland.harvard.edu> [100513 14:32]: >> On Thu, 13 May 2010, Tony Lindgren wrote: >> >> > The difference between echo mem > /sys/power/state and suspend blocks >> > is that with suspend blocks the system keeps running. >> >> Irrelevant. �Paul wasn't talking about the suspend blockers; he was >> talking about opportunistic suspend. �So what's the difference between >> opportunistic suspend and "echo mem >/sys/power/state"? �Especially >> when suspend blockers aren't being used? > > Opportunistic suspend is really trying to do runtime PM, see below. > >> > And that's why >> > it should be handled by runtime power management instead. >> >> Runtime PM is not capable of freezing userspace and shutting down CPUs. >> More or less by definition -- if it could then it wouldn't be "runtime" >> any more, since the processor wouldn't be running. > > Not true. We are already powering off CPUs and rebooting them for > at least omaps in every idle loop using cpuidle. The memory stays on. I agree with you Tony. I thought shutting down CPUs for power managment purposes could be done without freezing user space. At least that's what we do today with SH-Mobile. I don't dislike the idea of freezing a misbehaing user space app, but I wonder if hardware platforms really need this. I think hardware requirements and software requirements should be kept separated. There seem to be some confusion regarding what Runtime PM can and can not do. For SH-Mobile we use Runtime PM to manage the clocks and power supply to on-chip I/O devices, and from CPU idle context we check the state of the Runtime PM devices and decide what level of CPU deep sleep we can enter. You can call this system CPU deep sleep if you'd like depending on the dependencies are layed out on your hardware platform. For CPU deep sleep we more or less always stop the clock so we need to put the memory in self-refresh to avoid loosing memory contents. In some cases the deep sleep means that the power to the CPU core will be cut, so a more advanced context save/restore path needs to be used. Still not sure how the system wide suspend is different from Runtime PM and CPUidle from the hardware perspective... / magnus -- 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: Kevin Hilman on 14 May 2010 12:10 Matthew Garrett <mjg(a)redhat.com> writes: > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > >> The system stays running because there's something to do. The system >> won't suspend until all the processors hit the kernel idle loop and >> the next_timer_interrupt_critical() returns nothing. > > At which point an application in a busy loop cripples you. I think we > could implement your suggestion more easily by just giving untrusted > applications an effectively infinite amount of timer slack, > > but it still doesn't handle the case where an app behaves > excrutiatingly badly. Is design for exruciatingly bad apps a design requirement? If so, opportunistic suspend + suspend blockers fails as well. An app could easily hold a suspend blocker during its entire execution crippling PM. Using opportunistic suspend may possibly allow you contain bad apps/drivers, but at the cost of having to patch already working and trusted apps and known-working kernel code with suspend blockers. IMO, rather than accepting a solution that allows bad apps to run wild, it would be much better to _continue_ focus on tools for finding and containing bad apps. This approach has the added bonus of solving problems on *every* linux-based system, not just Android. Kevin -- 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: Kevin Hilman on 14 May 2010 12:20 Magnus Damm <magnus.damm(a)gmail.com> writes: > Still not sure how the system wide suspend is different from Runtime > PM and CPUidle from the hardware perspective... At least on OMAP and other embedded SoCs I'm familiar with, there is no difference from the hardware perspecitve. However, I understand that on ACPI-based systems, there are low-power that are only reachable via system-wide suspsend since ACPI does not provide the kernel with fine-grained control to hit those states during idle. That being said, I don't think this should be an issue since opportunistic suspend is currently targetted primarily at embedded HW which has much more fine-grained power control than traditional ACPI-based systems. To me the only real difference between system-wide suspend and runtime PM + CPUidle is the freezing of userspace. As has been discussed elsewhere in this discussion, any alternative solution must address the freezing/idling of userspace. Kevin -- 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: Daniel Walker on 14 May 2010 12:50 On Thu, 2010-05-13 at 14:46 -0700, Greg KH wrote: > On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: > > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: > > > > > Because someone would have to remove suspend blockers (or rather wakelocks) > > > from the drivers, test that they work correctly without suspend blockers and > > > submit the modified versions. Going forward, every party responsible for such > > > a driver would have to maintain an out-of-tree version with suspend blockers > > > (or wakelocks) anyway, so the incentive to do that is zero. > > > > They should work without wakelock since wakelock are optional .. I mean > > there's nothing in suspend blockers I've seen that indicates it's > > required for some drivers to work. So it's just a matter of patching out > > the wakelocks, with no need to re-test anything. > > > > You get the driver mainlined, then maintain a small patch to add > > wakelocks. Not hard at all , with lots of incentive to do so since you > > don't have to maintain such a large block of code out of tree. > > Sorry, but it doesn't seem to work that way. Look at the large number > of out-of-tree android device drivers that remain sitting there because > of the lack of this interface being in the kernel. I don't think that's due to this interface tho. During your CELF presentation you noted several bits of code that could go in right now but haven't (and still haven't as far as I've seen). I'm actively pushing code related to Android (with wakelocks removed).. Putting a wakelock contingency on everything to me doesn't make much sense. > Also note that such a driver, without wakelocks, would never get tested, > and so, things start quickly diverging. That's not totally true. For example the MMC driver had wakelocks (I think, or for sure mmc core does), and the MMC driver has been tested for G1 and works fine so far without them. I have code that is queued for my tree that will enable MMC on G1. I can merge Nexus one support through my tree also which would allow all the drivers for that device to eventually be used. With that device support in mainline then those drivers become nice things to have with or with out wakelocks. You don't need wakelocks to run Debian or anything else except Android. Daniel -- 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: Kevin Hilman on 14 May 2010 16:50
"Rafael J. Wysocki" <rjw(a)sisk.pl> writes: > On Thursday 13 May 2010, Tony Lindgren wrote: >> * Rafael J. Wysocki <rjw(a)sisk.pl> [100513 14:16]: [...] >> >> > It solves a practical issue that _at_ _the_ _moment_ cannot be solved >> > differently, while there's a growing number of out-of-tree drivers depending >> > on this framework. We need those drivers in and because we don't have any >> > viable alternative at hand, we have no good reason to reject it. >> >> Nothing is preventing merging the drivers can be merged without >> these calls. > > And yet, there _is_ a growing nuber of drivers that don't get merge because > of that. That's _reality_. Are you going to discuss with facts, or what? It may be reality, but IMO, "preventing other drivers" isn't a good *technical* argument for merging a feature. It feels like these "for the 'good' of the community" arguments are being used to trump the technical arguments. Maybe we need to keep the separate. Distros (especially embedded ones) have long had out of tree features that create barriers to getting other drivers upstream. While it might be nice to see all those features upstream, no one has argued that they should get merged simply because they create a barrier. Each feature should be merged on its own technical merit. Kevin -- 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/ |