| |||||||||||||
Current best guess at Android suspend-blocker requirementsCurrent best guess at Android suspend-blocker requirementsPosted Oct 2, 2011 23:43 UTC (Sun) by neilbrown (subscriber, #359)In reply to: Current best guess at Android suspend-blocker requirements by PaulMcKenney Parent article: A new approach to opportunistic suspend
Yes and no.
Some of John's patches were just bug-fixes. The wakeup event from the CMOS timer wasn't being counted as a wakeup event properly. Those patches I wasn't trying to re-implement - they are good.
The other patches from John did things to the scheduler so that distinguished processes could prevent suspend just by being busy. I was trying to show that these patches were not necessary because a completely race-free protocol is available in userspace.
(and finally there was a patch which tried to make /sys/power/state resistant to processes that didn't follow the wakeup_count protocol. That issue is best addressed by fixing the processes, or bind-mounting a file over /sys/power/state).
(Log in to post comments)
Current best guess at Android suspend-blocker requirements Posted Oct 3, 2011 16:18 UTC (Mon) by PaulMcKenney (subscriber, #9624) [Link]
Cool! But I must defer to John and the Android guys at this point, as they would have a better idea of what works and does not in the Android environment.
My guess is that if they needed something lighter weight, this same general approach could be implemented within a device driver, though an implementation that just used existing user-space interfaces would be preferable, all else being equal. (Which it never is, but that is life!)
|
|||||||||||||