[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: Ben Gamari on 27 May 2010 22:20 On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler <florian(a)mickler.org> wrote: > Because he is using a robust kernel that provides suspend blockers and > is preventing the vampire from sucking power? > Suspend blockers are only a flawed and indirect way to keep the vampire from sucking. > Most users don't even grasp the simple concept of different "programs". > They just have a device and click here and there and are happy. > > Really, what are you getting at? Do you deny that there are programs, > that prevent a device from sleeping? (Just think of the bouncing > cows app) He's getting at the fact that there are much better ways to deal with this problem. The issue here is that we seem to be expected to swallow whatever Google throws at us, regardless of the quality of the solution. It seems like the best argument we have for merging is "we couldn't think of anything better and we need it yesterday." This might be a good enough reason for shipping, but it certainly doesn't satisfy the requirements for merging. > > And if you have two kernels, one with which your device is dead after 1 > hour and one with which your device is dead after 10 hours. Which would > you prefer? I mean really... this is ridiculous. It is absolutely not. If you want to keep power usage down, then implement real resource management in the scheduler. Suspend blockers are nothing but a clunky and ineffective means of resource allocation. As has been pointed out in this thread, there are much better ways of dealing with this problem. - Ben -- 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: Arve Hjønnevåg on 27 May 2010 22:50 On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> 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. > Android does not only run on phones. It is possible that no android devices have ACPI, but I don't know that for a fact. What I do know is that people want to run Android on x86 hardware and supporting suspend could be very benficial. > I would imagine the existing laptops will handle power management limited > by the functionality they have available. Just like any other piece of > hardware. I think existing laptops (and desktops) can benefit from opportunistic suspend support. If opportunistic suspend is used for auto-sleep after inactivity instead of forced suspend, the user space suspend blocker api will allow an application to delay this auto sleep until for instance a download completes. This part could also be done with a user-space IPC call, but having a standard kernel interface for it may make it more common. A less common case, but more critical, is RTC alarms. I know my desktops can wakeup at a specific time by programming an RTC alarm, but without suspend blockers how do you ensure that the system does not suspend right after the alarm triggered? I have a system that wakes up at specific times requested by my DVR application, but I cannot use this system for anything else unless I manually turn off the DVR application's auto-sleep feature. With suspend blockers and something like the android alarm driver, I could use this system for more than one application that have scheduled tasks and it would be more usable for interactive applications. -- Arve Hj�nnev�g -- 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: tytso on 28 May 2010 00:40 On Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote: > > 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. Keep in mind, though, that a solution which is acceptable for Android has to include making sure that crappy applications don't cause the battery to get drained. There seem to be some people who seem adamently against this requirement. From the Android folks' perspective, this is part of what is required to have an open app store, as opposed to one where each application has to be carefully screened and approved ala the Apple iPhone App Store. Maybe it would be acceptable if there were an easy way THAT A USER AND NOT A DEVELOPER COULD USE ON A SMART PHONE to find the bad application, but realistically, it's much better if the solution can work well even in the face of crappy application. Having interacted with application programmers, I can assure you there are a lot of crappy application programmers out there, and they vastly outnumber us kernel developers. (See as exhibit A all of the application programs who refuse to use fsync, even though it's going to wipe them out on all new modern file systems, including btrfs.) We need to agree on the requirements up front, because otherwise this is going to be a waste of everyone's time. And if we can't get agreement on requirements, I'd suggest appealing this whole thing to Linus. Either he'll agree to the requirements and/or the existing implementation, in which case we can move on with our lives, or he'll say no, in which case it will be blately obvious that it was Linux developer community who rejected the Android approach, despite a fairly large amount of effort trying to get something that satisfies *all* of the various LKML developers who have commented on this patch, and we can continue with Android having kernel which is different from mainline --- just as many other embedded companies have patches which are utterly required by their products, but which have been judged Too Ugly To Live In Mainline --- and we can also move on and get on with our lives. - Ted P.S. Keep in mind how this looks from an outsider's perspective; an embedded manufacturer spends a fairly large amount of time answering one set of review comments, and a few weeks later, more people pop up, and make a much deeper set of complaints, and request that the current implementation be completely thrown out and that someone new be designed from scratch --- and the new design isn't even going to meet all of the requirements that the embedded manufacturer thought were necessary. Is it any wonder a number of embedded developers have decided it's Just Too Hard to Work With the LKML? -- 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 28 May 2010 01:00 On Thu, May 27, 2010 at 3:55 PM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > > 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 think that the suspend block model can be viewed as a constraints problem (similar to some of things things you've been sketching out in these threads), but I think we (Google/Android) view it as more of a state constraint (don't enter suspend) than a latency constraint. We think there's a need for these constraints both from the driver side and userspace side, and that these constraints are not tied to processes (multiple entities in one process may have different constraints at different times or multiple processes may be working together to accomplish some goal under a single constraint -- at least both cases exist in the Android system as it ships today). The exact naming of the API is not terribly important to us. The first thing we spent a bunch of time discussing last summer when Arve first looked into sending wakelocks upstream was changing the name because many objected to "wakelock" for various reasons. Being able to have userful statistics (which drivers/processes/etc held which wakelock for how long, how many times, etc) is important to us. While we want to do the best we can in the face of poorly written apps, we also want to educate users and developers about which apps are contributing to their poor battery life -- so users can decide to uninstall an app if its usefulness does not justify its impact on battery life and application developers can be more aware of what the cost of their app is to endusers. As an example, http://frotz.net/misc/battery-stats-unplugged.txt contains a dump from the "battery service" aggregating wakelock usage, cpu usage, and sensor device usage of processes (#....: sections) on my phone the other day for a ~3 hour period. This data is presented visually to the enduser in a "what's using my battery" feature of the platform. "realtime" refers to wall clock time here and "uptime" refers to not-in-suspend execution time. 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: Peter Zijlstra on 28 May 2010 01:20
On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote: > On Thu, 27 May 2010, Peter Zijlstra wrote: > > > I still don't see how blocking applications will cause missed wakeups in > > anything but a buggy application at worst, and even those will > > eventually get the event when they unblock. > > > > What seems to be the confusion? > > During forced suspend, applications are block because they are frozen. > > When an event occurs, the application is notified somehow. But it > can't respond because it is frozen. Hence the event remains sitting in > a kernel queue and the system goes ahead and suspends anyway. The > application doesn't get thawed until the system wakes up at some > indefinite time in the future. If the kernel is awake to put things in queues, we're clearly not suspended and userspace is running ?! -- 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/ |