Message-ID: <1294772163.3441.42.camel@work-vm>
Date:	Tue, 11 Jan 2011 10:56:03 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Arve Hjønnevåg <arve@...roid.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	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

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


--
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