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

[mark gross]

On Mon, Oct 24, 2011 at 12:50:34PM +1100, NeilBrown wrote:
> On Sun, 23 Oct 2011 18:18:04 -0700 mark gross <markgross@xxxxxxxxxxx> wrote:
> 
> > Sorry for going AWOL on this thread.  I had some biz travel and fires to
> > fight.
> 
> :-)  Life happens.  Welcome back.
> 
> 
> > > So it is a good example and highlights the difficulty of defining exactly
> > > what a wake-up event it, and of what it means to be "visible".
> > > 
> > > I think it still fits in your rephrasing of my question which - if I rephrase
> > > it as a requirement - is roughly,
> > > 
> > >   A wakeup-event that needs to be handled by user-space must be visible to
> > >   user-space before the driver deactivates the wakeup_source.
> > > 
> > > A requirement which, in this case, means the driver needs to hold  the
> > > wakeup_source for an extended time using a timeout, just as you say.
> > 
> > Timeout?  why can't we define a proper notification handshake for such
> > things?  Timeouts are never right IMO.
> > 
> 
> I thought that before, but I have come around to the opposite way of thinking
> thanks to some instructive examples from Alan and Rafael.
> 
> Some things are simply not visible to the OS.  We can expect them to be
> happening but we cannot be sure and there is no clear signal that they aren't
> actually happening.  So we need a timeout.

um

> 
> - OS cannot detect state of user's brain, so uses a time-out to blank the
>   screen after a period of inactivity.
true, but user interaction has not been part of this discussion.  The
ability of usermode code to offer user interaction has.

> - USB cannot (I think) know which USB device triggered a wake-from-suspend,
>   and in any case cannot directly ask the device why it woke from suspend.
>   It has to wait for the device to tell it (in response to a regular
>   'interrupt' poll I assume - but it isn't guaranteed to be reported on the
>   first poll) - or timeout and give up waiting.
maybe if you are unwilling to change the user mode stack that is reading
these events.  But if you where they you shouldn't need time outs.

> - A wake-on-Lan packet may wake a suspend up, but not be further visible to
>   the OS.  And even if it was, the 'SYN' packet or maybe 'ARP' packet that
>   might be expected to follow it is invisible until it actually arrives, and
>   it may not ever come.  So we need a timeout to give up waiting after a
>   while.
A time out here is just an optimization to avoid re-waking too often.

> 
> When-ever we are dealing with external events we need timeouts - and
> wake-from-suspend is primarily about external events.

This is going too far.   I see wakes up as very analogous to interrupt
devices.  We have interrupts no one seem to care about, and we tend to
have devices that don't time out waiting for an ACK from the OS, where
the OS needs to have a timeout for the latency of IRQ handling. 


> So *somewhere* in the handling of wakeup events there must be timeouts.
> Whether that should be explicit in the wakeup-source is possibly a separate
> question.  Maybe you could argue that the low level device driver must have
> timeouts anyway, so it should use them to explicitly deactivate the source
> rather than the source having it's own timeout.
> I'm not sure that argument would work though it might.
> But saying "Timeouts are never right" cannot work - unless you mean it in a
> much more restricted sense than I think you mean it.

I think they are never right.  But, accept that they are useful for some
case.  i.e. I think having them and using them is a hack to avoid
changing legacy programs dependent on the input subsystem where USB wake
events is a boundary case like the USB or optimizations as in the wake
on lan example. 

It should be possible to implement a system (if you are willing to do
the work) that is correct without timeouts.

> (I can agree that it is *best* if timeouts never fire - if direct action
> causes the wakeup-source to deactivate long before the timeout.  I agree that
> is the best case and probably should be the common case, but I cannot see how
> it can be the only case).

well I still maintain that as a practical matter whatever time out value
chosen is wrong for someone, in some way.  I can't stress this point
enough.  I really worry about *possibility* of correctness whenever a
time out is considered as part of an API.

Time outs may be needed but, I don't think they should be part of the
core API's other than seldom used special needs API for the occasional
corner case.

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