[lkml]   [2011]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers
2011/1/11 John Stultz <>:
> On Wed, 2011-01-05 at 20:07 -0800, Arve Hjønnevåg wrote:
>> I don't know how suited the posix interface is for this, but I think
>> it is critical to prevent suspend while an alarm is pending. If an
>> alarm is important enough to wake the system up from suspend, it is
>> probably not safe to suspend right after it triggered. The android
>> alarm driver holds a wakelock until user-space calls back in to wait
>> for the next alarm, while in-kernel alarms are called from interrupt
>> context. The apis provided in include/linux/pm_wakeup.h should provide
>> the functionality you need to prevent suspend until the alarms have
>> been fully processed, but I have not tried this api yet.
> So again, I was really hoping to avoid wading into the wakelocks
> discussion. However, I'm hesitant to push the posix alarm timers
> interface into the kernel if it is insufficient to replace the android
> alarm driver.  Wakelocks are not upstream, so they shouldn't block
> upstream progress, but I don't want to create an interface that ends up
> being short sighted if some wakelock-like solution were to later be
> included upstream.
> So into the water i slowly wade.
> I've been thinking about Arve's example above. The part that concerns me
> the most is the implicit suspend blocker that is acquired by the kernel
> when the alarm fires in order to inhibit suspend during the user-space
> processing until the process calls back into the alarm device.
> I was considering various ideas, like a special signal that tells
> userland that it holds a wakelock and is responsible for dropping it. Or
> some sort of callback when signal handling is complete by userland
> allowing userland to grab its own lock and let the kernel drop its held
> lock.
> But in my mind, it seems it would be cleaner if the userland application
> did something to mark itself as inhibiting suspend. Then if it was to
> block waiting on something like an alarm timer, the kernel would drop
> the suspend blocker. Then when the alarm timer fires, the kernel would
> re-aquire the suspend-blocker for the process when waking it up (the
> kernel may do its own suspend inhibition internally as well - but there
> wouldn't be any cross kernel/userland implicit lock passing). This is
> sort of like SCHED_FIFO 99 style semantics, where a realtime process
> won't be preempted unless it explicitly blocks.
> I realize this might be more complicated, as suspend inhibition might be
> desirable while a process is blocked, such as waiting on the disk, or
> blocking on non-alarm triggering timers (although that seems wasteful).
> But it seems that any blocking on devices that trigger wakeups would be
> fine time for us to drop suspend blocker, as we know we will be woken up
> after that point.
> Arve: Would something like the above resolve the issue you brought up? I
> realize Android might not be eager to convert to some new semantics,
> (nor the upstream kernel be eager to start using optimistic suspend),
> but should that day come, do you think such a solution would be
> sufficient?
> thanks
> -john

This is offtopic, but I set 60 minutes on my system until it suspends.
And 5 minutes for the screen.
I move my mouse, to avoid the suspend.
This is not the most trivial way of suspend blocker ?
If I see an movie on my pc, I want the movie app to be a suspend
blocker, because I want to see it until it finishes.
But what if I go away ? Then some sensor will tell to pause the movie,
and suspend.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-01-11 20:25    [W:0.131 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site