Date:	Tue, 11 Jan 2011 21:22:56 +0200
From:	Anca Emanuel <anca.emanuel@...il.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Brian Swetland <swetland@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers

2011/1/11 John Stultz <john.stultz@...aro.org>:
> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists