Date:	Thu, 27 May 2010 17:59:31 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arve Hjønnevåg <arve@...roid.com>,
	Florian Mickler <florian@...kler.org>,
	Vitaly Wool <vitalywool@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul@...p1.linux-foundation.org, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > No. Suspend blockers are designed to ensure that suspend isn't racy with 
> > respect to wakeup events. The bit that mitigates badly written 
> > applications is the bit where the scheduler doesn't run any more.
> > 
> > If you're happy with a single badly written application being able to 
> > cripple your power management story, you don't need opportunistic 
> > suspend. But you still have complications when it comes to deciding to 
> > enter suspend at the same time as you receive a wakeup event.
> 
> Wrong. Setting the QoS requirements of the badly written app to any
> latency will allow the kernel to suspend even if the crappy app is
> active.

That's not what I want if I'm using the app at the time...

> And again. I'm opposing the general chant that fixing crappy
> applications in the kernel is a good thing. It's the worst decision we
> could make.

You still need the in-kernel suspend blockers if you want to guarantee 
that you can't lose wakeup events. But yes, if you're not concerned 
handling badly behaved applications then I believe that you can lose 
opportunistic suspend and just use the scheduler.

> The whole notion of treating suspend to RAM any different than a plain
> idle C-State is wrong. It's not different at all. You just use a
> different mechanism which has longer takedown and wakeup latencies and
> requires to shut down stuff and setup extra wakeup sources.

My question was about explicit suspend states, not implicitly handling 
an identical state based on scheduler constraints. Suspend-as-a-C-state 
isn't usable on x86 - you have to explicitly trigger it based on some 
policy. And if you want to be able to do that without risking the loss 
of wakeup events then you need in-kernel suspend blockers.

> I'm starting to get really grumpy about the chant that suspend
> blockers are the only way to fix missed wakeups. That might be the
> only way you can think of with your pink android glasses on, but again
> this is not rocket science even if it does not fit into the current
> way the kernel handles the whole suspend mechanism.

I don't work for Google. I'm not an Android developer.

> So if we really sit back and look at suspend as another idle state,
> then we have first off the same requirements for entering it as we
> have for any other idle state:

There are various platforms where we cannot treat suspend as an idle 
state. Any solution that requires that doesn't actually solve the 
problem. Yes, this is *trivial* if you can depend on the scheduler. But 
we can't, and so it's difficult.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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