| |||||||||||||
Waking systems from suspendWaking systems from suspendPosted Mar 3, 2011 16:49 UTC (Thu) by PaulMcKenney (subscriber, #9624)In reply to: Waking systems from suspend by johill Parent article: Waking systems from suspend Are there any good interfaces? Well, yes there are, but unfortunately, different groups have wildly conflicting definitions of what constitutes “good”. The Android developers swear by wakelocks, but wakelocks have not been warmly received by many in the Linux kernel community (see here, here, here, here, here, here, here, and here). Many in the Linux kernel community swear by extensions to PM QOS, but the Android developers do not believe that these extensions are capable of replacing wakelocks — though these extensions might allow Android device drivers to be accepted into mainline, which would be very worthwhile in and of itself. Hey, you asked!!! ;–)
(Log in to post comments)
Waking systems from suspend Posted Mar 3, 2011 17:11 UTC (Thu) by johill (subscriber, #25196) [Link]
:-) I'm genuinely interested since we'll eventually run into more of this on more platforms, say a tablet.
The APIs you mention, do they actually allow you to know what device woke up the system? I thought they were mostly for not going to suspend.
Waking systems from suspend Posted Mar 3, 2011 17:52 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link]
The trick used is a handoff of responsibility from the kernel to userspace. Userspace knows what device woke up the system because it just interacted with the corresponding device driver, and can then decide whether or not to continue holding off suspend. The kernel therefore only needs to hold off suspend until userspace has started the interaction, where this interaction might be a read() system call. So userspace would hold off suspend just before doing the read(). The kernel would stop holding off suspend as part of the read(). After the read() returned, userspace would use the data read to determine whether it should keep holding off suspend, and, if not, stop holding off suspend.
According to the Android developers, wakelocks handle this handoff in a natural way. Others argue that all of the suspend-blocking work should happen in user space, so that the kernel does not need to worry about it. And there are probably a large number of other opinions out there about how all of this should work, both informed and otherwise. ;-)
Waking systems from suspend Posted Mar 5, 2011 7:48 UTC (Sat) by swetland (subscriber, #63414) [Link]
We (the Android Kernel Team) expect that we will be able to move to the driver level API side of the wakelock/suspendblock work to shift our driver work to be mainline-friendly.
The last proposals I've seen around userspace interface and suspend interface involve polling/spinning and I doubt we'll make use of them. The nice thing is this is pretty localized so it'll be easy enough to maintain patches for a reasonable userland interface on our side and not have to worry about any special changes for drivers. A nice step forward.
Regarding timer interfaces, are there non-signals-based ways of interacting with posix timers? Being able to select() on an fd for an alarm event works very well for us now and we're not terribly keen on moving to a signals-based universe.
Waking systems from suspend Posted Mar 5, 2011 23:34 UTC (Sat) by jstultz (subscriber, #212) [Link]
clock_nanosleep() might be one possibility?
Although from my brief discussions with Arve it sounded like the semantics of the android alarm timer interface is a little particular (especially with regards to wakelocks), so I doubt there will be an alternate implementation that will provide an exact 1:1 mapping.
That said, the rework of the RTC layer as well as the implementation of CLOCK_BOOTTIME (tglx just pulled it into -tip) will hopefully greatly simplify the android alarm timer code. So there may be a future for both the posix alarm timers and some form of the /dev/alarm device to co-exist, sharing a good bit of code.
Even so, while I think the posix interface for alarm timers provides a fairly nice and consistent interface that application developers are used to using, I'd greatly appreciate feedback and suggestions for alternative interfaces. Maybe we need something like clock_select()?
Waking systems from suspend Posted Mar 7, 2011 14:39 UTC (Mon) by alonz (subscriber, #815) [Link] Wouldn't it be better to just enhance timerfd() so it can take these new types of clock IDs as well as CLOCK_REALTIME / CLOCK_MONOTONIC?
Waking systems from suspend Posted Mar 7, 2011 18:16 UTC (Mon) by jstultz (subscriber, #212) [Link]
That might be a good approach. I'll look into it!
|
|||||||||||||