From: Peter Zijlstra on
On Thu, 2010-05-27 at 18:16 +0100, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > > No. The useful property of opportunistic suspend is that nothing gets
> > > scheduled. That's fundamentally different to a deep idle state.
> >
> > I think Alan and Thomas but certainly I am saying is that you can get to
> > the same state without suspend.
> >
> > Either you suspend (forcefully don't schedule stuff), or you end up
> > blocking all tasks on QoS/resource limits and end up with an idle system
> > that goes into a deep idle state (aka suspend).
> >
> > So why isn't blocking every task on a QoS/resource good enough for you?
>
> Because you may then block them in such a way that they never handle an
> event that should wake them.

*blink*, do explain?

Suppose X (or whatever windowing system) will block all clients that try
to draw when you switch off your screen.

How would we not wake them when we do turn the screen back on and start
servicing the pending requests again?

Pretty much the same for everything else, input events, WoL etc..


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on
On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Felipe Balbi wrote:
>
> > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > >If people don't mind, here is a greatly simplified summary of the
> > >comments and objections I have seen so far on this thread:
> > >
> > > The in-kernel suspend blocker implementation is okay, even
> > > beneficial.
> >
> > I disagree here. I believe expressing that as QoS is much better. Let
> > the kernel decide which power state is better as long as I can say I
> > need 100us IRQ latency or 100ms wakeup latency.
>
> Does this mean you believe "echo mem >/sys/power/state" is bad and
> should be removed? Or "echo disk >/sys/power/state"? They pay no

mem should be replaced by an idle suspend to ram mechanism

> attention to latencies or other requirements.

s2disk is a totally different beast as it shuts down the box into the
complete power off state.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
> > Opportunistic suspend is just a deep idle state, nothing else.
>
> No. The useful property of opportunistic suspend is that nothing gets
> scheduled. That's fundamentally different to a deep idle state.

Nothing gets scheduled in a deep idle state either - its idle. We leave
the idle state to schedule anything.

I believe the constraint is

- Do not auto-enter a state for which you cannot maintain the devices in
use "properly".

On a current PC that generally means 'not suspend', on a lot of embedded
boards (including Android phones) it includes an opportunistic 'suspend'
and also several states half way between the PC deepest idles and suspend.

> > Stop thinking about suspend as a special mechanism. It's not - except
> > for s2disk, which is an entirely different beast.
>
> On PCs, suspend has more in common with s2disk than it does C states.

Todays PCs are a special case. More to the point I don't think anyone is
expected opportunistic suspend to be useful on _todays_ x86 systems.

Even on todays PCs your assumption is questionable for virtual machines
where a VM suspend is a lot faster and rather useful.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on
On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:

> Suppose X (or whatever windowing system) will block all clients that try
> to draw when you switch off your screen.
>
> How would we not wake them when we do turn the screen back on and start
> servicing the pending requests again?

How (and why) does the WoL (which may be *any* packet, not just a magic
one) turn the screen back on?

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on
On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:

> Even if we could use suspend-via-deep-idle-state on PCs,

( see Alan Cox's argument on PCs )

> we still need to be able to enter suspend while the system isn't idle.

_WHY_!?

We've been trying to tell you you don't need that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/