[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: Rafael J. Wysocki on 27 May 2010 17:20 On Thursday 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote: > > > > They may be different conceptually. Nevertheless, Android uses forced > > suspend as a form of power saving. Until better mechanisms are in > > place, it makes sense. > > So let them, doesn't mean we have to merge it. Or will you saw your foot > off too if google were to promotes it? Do you have to be offensive to people who disagree with you? Alan simply wants to understand the _technical_ objections that people have to this patchset and you're not helping. So, could you please explain what exactly is your technical objection to it? 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 Cox on 27 May 2010 17:20 > That's the point -- suspend does not evaluate the system state > correctly because it doesn't have the necessary information. Suspend The power management layer knows if the machine is idle, it has insight into when the next wakeups will occur. > blockers are a way of providing it that information. They don't paper > over the problem; they solve it. I'm still unconvinced (see Thomas examples as a starter) and even if they did, the cure would be far worse than the disease. The hardware world also shows how you handle suspend/resume event races cleanly and in turn how we can handle right from user to hardware. If you are dealing with a well behaved UI app then its event loop will just do if (message == UI_OFF) { stop_background_stuff(); event_mask &= stuff; send_reply(NIGHT_NIGHT); continue; /* Back to poll() */ } and power management does the rest. If an event wakes up the process before we get to suspend in kernel we will wake it back up. If the event gets in after pm decides to idle via suspend then it'll bounce through the kernel back to a kernel resume, or potentially through a full hardware/software suspend/resume bounce. You have one person who needs to track the sequence - that's however is the guy sending UI_ON/UI_OFF information and making the screen light up. If you are dealing with a badly behaved app then you can't win because it may not have the magic 'suspend blockers' or will do it wrong. You can constrain it (brute force SIGSTOP after it refuses to UI_OFF for a bit, or via nice or other QoS policy) but you can't assume it'll magically managge itself. It is "badly behaved" so by that very definition you can't assume it has correct magic goo in it. (Side note: the extra magic goo and complexity of such blockers makes it more likely the app will be buggy and thus 'badly behaved' !) You can pick up which tasks are stopping the suspend fairly easily at the moment via the ktrace interfaces. Maybe there is a case for making that tidier but powertop and the like already demonstrate you can track this. A cpu policy can obviously expose offenders itself directly to user space. That (and indeed people not responding to UI_OFF) then lets your phone do <boop> X is misbehaving [Close it] [Allow this time] [Disable] and also to provide stats for each wakeup a policy manager can spot offenders (even those who are perhaps hard to see because they wake up a little bit every so often but just enough to mess up pm). In the x86 world Arjan found a *lot* of that sort of stuff. Your policy manager can also act on it. The current policy manager is to fix app bugs and shows people up at conferences. I would imagine a google policy would be to collate misbehaving app reports at google.com and use them both to assist in 'educating' authors and in scoring app store stuff. As it is <boop> X is misbehaving is a powerful economic lever in a pretty dynamic and functioning software market. Google seem to be pretty good at statistical data, I can't believe battery advice for apps on the app stores and indeed a 'where did my battery go' pie chart are beyond their wit, or beyond the end user to figure out. There are a considerable number of people shipping power constrained Linux devices without suddenely desperately needing extra magic potions. Are they really all just that much smarter than Google ? 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: Matthew Garrett on 27 May 2010 17:30 On Thu, May 27, 2010 at 05:24:28PM -0400, Alan Stern wrote: > Would it help to divide the application into two processes, one of > which receives events and the other does the drawing? At the point where you're rewriting the application you can just make it adhere to our current behavioural standards anyway. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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 17:30 On Thu, 27 May 2010 13:29:18 -0400 (EDT) Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Thu, 27 May 2010, Peter Zijlstra wrote: > > > On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote: > > > > > > 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 > > > attention to latencies or other requirements. > > > > Those are a whole different beast, those are basically a quick-off > > button like thing. Forced suspend is conceptually a very different beast > > from power-saving a running system. > > They may be different conceptually. Nevertheless, Android uses forced > suspend as a form of power saving. Until better mechanisms are in > place, it makes sense. For them, not for Linux. Several vendors have exciting kernel drivers that do things like binary patch other modules. Until better mechanisms are in place it does *NOT* make sense to merge such stuff. I don't care what they do in their own tree (consenting adults in their own home and all that) but what they do in the public tree is another matter. 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: Alan Stern on 27 May 2010 17:30
On Thu, 27 May 2010, Matthew Garrett wrote: > > > Doesn't help - I may be hit by the signal between the poll() unblocking > > > and me having the opportunity to call sigmask(). > > > > ppoll(). This is all existing solved stuff. > > Isn't that the inverse of what we want? The application should default > to being SIGSTOPpable except in the case of it being in the process of > having a specific event delivered. Would it help to divide the application into two processes, one of which receives events and the other does the drawing? 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/ |