Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

[John Stultz <john.stultz@linaro.org>]

On Wed, 2011-09-28 at 10:59 +0200, Peter Zijlstra wrote:
> On Tue, 2011-09-27 at 15:56 -0700, John Stultz wrote:
> > 
> > But I also want to separate my specific solution from the problem at
> > large. I do think that there are issues that my proposal and wakelocks
> > address that the hand-wavy "just do it in userspace" rebuttals don't
> > deal with (again specifically: wakeup event consumption in userland
> > before the next suspend). 
> 
> You know, once you drop the whole suspend notion that race goes away.
> 
> Esp. on the mobile hardware there really isn't anything different
> between a deep idle state and suspend.

Well, except timer noise and device irq noise.

> So just make the thing idle and your suspend race goes away.

Maybe hardware vendors will surprise me, but I don't think the power
difference between suspend and idle will get close enough in a
reasonable amount of time on server hardware.

Even then, I doubt you'll see standard distros that get minutes of
un-interrupted deep-idle. 

How long until you realistically expect to leave your laptop overnight
off of AC without suspending it (and not have it be on fumes in the
morning)? 

> There's still things like the cgroup-freezer if you really want to force
> stuff down, but really your core system should be sane and not actually
> do anything unless asked.

I think the cgroup-freezer is closer to the lines I'm thinking of, but
with the potential to do "importance" inheritance so interactions
between tasks in different groups (be they cgroups or sched classes) can
work normally.

thanks
-john