Messages in this thread | | | Date | Wed, 12 Jan 2011 21:03:45 -0800 | Subject | Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers | From | Arve Hjønnevåg <> |
| |
On Sat, Jan 8, 2011 at 2:36 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Friday, January 07, 2011, John Stultz wrote: >> On Thu, 2011-01-06 at 16:58 -0800, Arve Hjønnevåg wrote: >> > 2011/1/6 John Stultz <john.stultz@linaro.org>: >> > > So otherwise, do you see any reason why android might not be able to >> > > adapt this code to replace the android alarm timers? >> > > >> > >> > The user-space interface does not look appealing, but I don't see any >> > reason why the in-kernel interface(s) cannot be shared. Our user-space >> > code has a single thread that waits for alarms to trigger, while the >> > alarms can be modified from any thread. >> >> So its something like nanosleep(), only other threads can extend or >> shorten the sleep time? >> >> Could you explain some of the rational for such an interface, so I can >> better understand the need? >> >> > As far as I can tell, using >> > the posix interface would either require a thread per alarm (up to 5) >> > or using signals. Both make the user-space code more complicated, and >> >> Yea, it probably would need signals, but I'd have to grok the use case a >> little better. And its possible it would complicate the user-space code >> some, but on the other hand, it would be using a more standard kernel >> interface. The other option is extending the posix interface to try to >> better match the need. >> >> > it is not clear if either of them provide a clear hand-off between >> > where the kernel needs to block suspend because the alarm has not been >> > delivered to user-space and where user-space needs to block suspend >> > because it is handling the alarm. >> >> Indeed. I'm still looking into the pm_wake details to see the >> limitations there. Some method of inheriting a stay_awake seems to be >> needed, but sounds pretty ugly. Alternatively we may need some method or >> callback to the kernel to detect that a signal has been handled by >> userland (allowing the pm_relax to occur). >> >> Rafael: Any thoughts here? > > I think this problem is specific to Android where suspend is started > automatically from kernel space, so user space needs an interface to actively > prevent the kernel from starting suspend. > > The mainline model is that suspend will always be started from user space, > so instead of telling the kernel not to suspend user space needs to avoid > starting suspend in the first place. In this model the kernel code can simply > call pm_relax() as soon as _it_ doesn't need to prevent the system from > suspending any more (eg. it knows that user space has learnt of the alarm) and > it need not worry about the user space part (eg. whether or not user space > is still handling the alarm). >
You still have to make sure a race free implementation is possible. If you are implementing alarms by calling nano-sleep, your model require the nano-sleeping thread to also respond to requests from the thread that initiates suspend when that thread checks if it is safe to suspend.
-- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |