From: Matthew Garrett on
On Thu, May 27, 2010 at 08:02:13PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
> > If you want to support forced suspend for laptops and you want to avoid
> > the risk of losing wakeups then you need in-kernel suspend blockers.
> > That's entirely orthogonal to Android's runtime power management.
>
> The simple fact of life is, on PC style hardware suspend is mostly about
> missing events. I really _really_ want to miss mouse movement of my
> bluetooth mouse when the gear is stowed in my backpack.

That's fine - those shouldn't be configured as wakeup events.

> Its perfectly OK to miss events on _forced_ suspend.

No, it's not. Forced suspend may be in response to hitting a key, but it
may also be in response to a 30 minute timeout expiring. If I get a WoL
packet in the 0.5 of a second between userspace deciding to suspend and
actually doing so, the system shouldn't suspend.

--
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: Thomas Gleixner on
On Thu, 27 May 2010, Matthew Garrett wrote:
> 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?

Very realistic scenario on a mobile phone.

--
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:05:15PM +0100, Alan Cox wrote:

> I'd prefer we avoided mixing them up. Everyone seems fairly happy with
> the current operator ordered suspend behaviour I believe ?

No. The current mechanism can lose wakeup events.

--
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 Cox on
> > So PCs with current ACPI don't get opportunistic suspend capability. It
> > probably won't be supported on the Commodore Amiga either - your point ?
>
> Actually, the reverse - there's no terribly good way to make PCs work
> with scheduler-based suspend, but there's no reason why they wouldn't
> work with the current opportunistic suspend implementation.

If one works so does the other.

> In some cases, not all. It may be a latency constraint (in which case
> pm_qos is an appropriate mechanism), but instead it may be something
> like "A key was pressed but never read" or "A network packet was
> received but not delivered". These don't fit into the pm_qos model, but
> it's state that you have to track.

I never mentioned pm_qos, just latency *and* knowing what suspend states
are acceptable. You need both.

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 08:06:38PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
> > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
> > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
> > >
> > > > If that's what you're aiming for then you don't need to block
> > > > applications on hardware access because they should all already have
> > > > idled themselves.
> > >
> > > Correct, a well behaved app would have. I thought we all agreed that
> > > well behaved apps weren't the problem?
> >
> > Ok. So the existing badly-behaved application ignores your request and
> > then gets blocked. And now it no longer responds to wakeup events.
>
> It will, when it gets unblocked from whatever thing it got stuck on.

It's blocked on the screen being turned off. It's supposed to be reading
a network packet. How does it ever get to reading the network packet?

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