From: Peter Zijlstra on
On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
>
> They may be different conceptually. Nevertheless, Android uses forced
> suspend as a form of power saving. Until better mechanisms are in
> place, it makes sense.

So let them, doesn't mean we have to merge it. Or will you saw your foot
off too if google were to promotes it?
--
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:28:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
> > How (and why) does the WoL (which may be *any* packet, not just a magic
> > one) turn the screen back on?
>
> Why would you care about the screen for a network event?

Because the application that needs to handle the network packet is
currently blocked trying to draw something to the screen.

--
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: Alan Stern on
On Thu, 27 May 2010, Peter Zijlstra wrote:

> On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:

> > > 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.
>
> 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?

On some platforms (like those with ACPI), deeper power-savings are
available by using forced suspend than by using idle. That used to be
the case on Android. Arve has said that it isn't necessarily true any
more, but that's the way their software is set up.

Alan Stern

--
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:24:02PM +0200, Thomas Gleixner wrote:

> Oh no. They paper over a short coming. If there is a pending event,
> the kernel knows that. It just does not make use of this
> information. Blockers just paper over this by sprinkling
> do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need
to be able to enter suspend while the system isn't idle. There's two
ways to do that:

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely
on the scheduler, we need drivers to know whether userspace has consumed
all wakeup events before allowing the transition to occur. Doing so
requires either in-kernel suspend blockers or something that's almost
identical.

--
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: Matthew Garrett on
On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
> > > Why would you care about the screen for a network event?
> >
> > Because the application that needs to handle the network packet is
> > currently blocked trying to draw something to the screen.
>
> Then that's an application bug right there, isn't it?
>
> If should have listened to the window server telling its clients it was
> going to go away. Drawing after you get that is your own damn fault ;-)

How long do you wait for applications to respond that they've stopped
drawing? What if the application is heavily in swap at the time?

--
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/