On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
quoted text
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > A wakeup event is defined as one that wakes the system - if a system 
> > can't be woken by a specific event then it's impossible to lose it, 
> > since it wasn't a wakeup event to begin with.
> 
> So where is the problem ?

The problem is that, right now, if a wakeup event is received between 
the point where userspace decides to start a suspend and userspace 
actually starts a suspend, that event may not abort the suspend.

quoted text
> > Consider the case where the read() is non-blocking.
> 
> Which I consider in the same range as the application which does:
> 
>       while (1);

Not at all. Depending on what it reads, it may follow some other path 
where it sleeps. But, as I keep saying, if you don't want to support 
that kind of code then all of this is massively easier.

quoted text
> > What sets that flag, and how does it interact with an application that 
> > never makes a blocking system call?
> 
>   QoS(NONE) would be default policy for untrusted apps in the same way
>   as you'd refuse the usage of supsend blockers for untrusted apps.
>
>   while (1); is definitely not an application which should be granted
>   trusted rights, right ?

No, but if that while (1) is draw_cows() then the user may want this to 
run while their session is active and stop running while their session 
is idle. So you only want it to be QoS(NONE) in the idle session case. 
How do you change that state?
 
quoted text
> > The numbers were earlier in the thread.
> 
>   Numbers, yes. But I really give a sh*t about numbers w/o a detailed
>   explanation of the scenario which created those numbers. And if the
>   numbers boil down to: we handle the untrusted app which does "while
>   (1);" then they are absolutely useless.

The tested case was a stock Android install with opportunistic suspend 
enabled and one that just used runtime idle. The lowest power state 
entered was the same on both.

quoted text
> > Yes, and I'd agree with this if anyone seemed to have any idea how to do 
> > it right. But despite all the heat and noise in this thread, all we've 
> > got is an expression that it should be handled by the scheduler (a 
> > viewpoint I agree with) without any explanation of how to switch 
> > policies in such a way that applications idle without losing wakeup 
> > events.
> 
> Why in the world should they lose wakeup events ? If an app goes idle,
> it goes idle because it is waiting for an event. There is no other
> sane reason except for those apps which are untrusted and force
> idled. And for those you agreed already the suspend blockers don't
> solve anything as they are either not implemented or the app is not
> trusted to use them.
>
> So we are back to round one of the whole discussion:
> 
>    Is it worth to create an utter mess in the kernel just to handle a
>    subset of crappy coded applications ?
> 
> And the answer stays the same: No, not at all.

You need suspend blockers to avoid losing wakeups in the explicit 
suspend case even if you don't want to implement opportunistic suspend.

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