Re: [markgross@thengar.org: [RFC] wake up notifications and suspendblocking (aka more wakelock stuff)]

[mark gross]

On Sat, Oct 08, 2011 at 10:14:39PM +1100, NeilBrown wrote:
> On Sun, 2 Oct 2011 09:44:56 -0700 mark gross <markgross@xxxxxxxxxxx> wrote:
> 
> > resending to wider list for discussion
> > ----- Forwarded message from mark gross <markgross@xxxxxxxxxxx> -----
> > 
> > Subject: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)
> > Date: Tue, 20 Sep 2011 13:33:05 -0700
> > From: mark gross <markgross@xxxxxxxxxxx>
> > To: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
> > Reply-To: markgross@xxxxxxxxxxx
> > Cc: arve@xxxxxxxxxxx, markgross@xxxxxxxxxxx, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>, amit.kucheria@xxxxxxxxxx, farrowg@xxxxxxxxxx, "Rafael J. Wysocki" <rjw@xxxxxxx>
> > 
> > The following patch set implement an (untested) solution to the
> > following problems.
> > 
> > 1) a method for making a system unable to suspend for critical sections
> > of time.
> 
> We already have this.  A properly requested suspend (following wakeup_count
> protocol) is unable to complete between wakeup_source_activate() and
> wake_source_deactivate() - these delimit the critical sections.
> 
> What more than this do you need?

sometimes devices that are not wake up sources need critical sections
where suspend is a problem.

> If user-space wants to prevent suspend, it just needs some sort of protocol
> for talking to the user-space process which follows the correct protocol to
> initiate suspend.  That isn't a kernel problem.

The devices that I've seen that need to block suspend don't have a
communication interface to user mode. 

But, you are right the devices that need this sort of thing could
register as wakeup sources and block suspend as well.

FWIW This part of the patch set was to wrap up a proposal I got last
year from some folks to try to provide somewhat compatible semantics to
wakelock's for the android and linux kernel community.

I include it for completeness. 
> 
> > 
> > 2) providing a race free method for the acknowledgment of wake event
> > processing before re-entry into suspend can happen.
> 
> Again, this is a user-space problem.  It is user-space which requests
> suspend.  It shouldn't request it until it has checked that there are no wake
> events that need processing - and should use the wakeup_count protocol to
> avoid races with wakeup events happening after it has checked.

Here you are wrong, or missing the point.  The kernel needs to be
notified from user mode that an update event has been consumed by
whoever cares about it before the next suspend can happen.  The fact
that there are time outs in the existing wake event code points to this
shortcoming in the current implementation.

I suppose one could rig up the user mode suspend daemon with
notification callbacks between event consumers across the user mode
stack but its really complex to get it right and forces a solution to a
problem better solved in kernel mode be done with hacky user mode
gyrations that may ripple wildly across user mode.

Also it is the kernel that is currently deciding when to unblock the
suspend daemon for the next suspend attempt.  Why not build on that and
make is so we don't need the time outs?

> i.e. there is no kernel-space problem to solve here (except for possible
> bugs).

Just a race between the kernel allowing a suspend and the user mode code
having time to consume the last wake event.

--mark

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/