On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > 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
> >
> > And why not ? Just because suspend is not implemented as an ACPI
> > C-state ?
> >
> > Nonsense, if we want to push the system into suspend from the idle
> > state we can do that. It's just not implemented and we've never tried
> > to do it as it requires a non trivial amount of work, but I have done
> > it on an ARM two years ago as a prove of concept and it works like a
> > charm.
>
> ACPI provides no guarantees about what level of hardware functionality
> remains during S3. You don't have any useful ability to determine which
> events will generate wakeups. And from a purely practical point of view,
> since the latency is in the range of seconds, you'll never have a low
> enough wakeup rate to hit it.
Right, it does not as of today. So we cannot use that on x86
hardware. Fine. That does not prevent us to implement it for
architectures which can do it. And if x86 comes to the point where it
can handle it as well we're going to use it. Where is the problem ? If
x86 cannot guarantee the wakeup sources it's not going to be used for
such devices. The kernel just does not provide the service for it, so
what ?
> > > 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.
> >
> > Crap. Stop beating on those lost wakeup events. If we lose them then
> > the drivers are broken and do not handle the switch over correctly. Or
> > the suspend mechanism is broken as it does not evaluate the system
> > state correctly. Blockers are just papering over that w/o tackling the
> > real problem.
>
> Ger;kljaserf;kljf;kljer;klj. Suspend blockers are the mechanism for the
> driver to indicate whether the wakeup event has been handled. That's
> what they're there for. The in-kernel ones don't paper over anything.
So the driver says: events have been handled. Neat.
Now if that crappy app does not use the user space blockers or is not
allowed to use them, then what are you guaranteeing ? All you
guarantee is that the application has emptied the input queue. Nothing
else. And that's the same as setting the QoS guarantee to NONE.
An application which uses the blocker is just holding off the system
from going into deep idle. Nothing which cannot be done today.
So the only thing you are imposing to app writers is to use an
interface which solves nothing and does not save you any power at
all.
If the application drops the blocker after processing the event and
before it goes back to the read event then you just postpone the CPU
usage and therefor power consumption to a later point in time instead
of going back to the blocking read right away.
Again what is it saving ? NOTHING! And for nothing you want to mess
up the kernel big time ?
Runnable tasks and QoS guarantees are the indicators whether you can
go to opportunistic suspend or not. Everything else is just window
dressing.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
