From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934906Ab0E0SSZ (ORCPT ); Thu, 27 May 2010 14:18:25 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:41751 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932501Ab0E0SSW (ORCPT ); Thu, 27 May 2010 14:18:22 -0400 Date: Thu, 27 May 2010 19:17:58 +0100 From: Matthew Garrett To: Peter Zijlstra Cc: Thomas Gleixner , Alan Cox , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Florian Mickler , Vitaly Wool , LKML , Paul@smtp1.linux-foundation.org, felipe.balbi@nokia.com, Linux OMAP Mailing List , Linux PM Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) Message-ID: <20100527181758.GJ3543@srcf.ucam.org> References: <20100527172510.GC2468@srcf.ucam.org> <1274981288.27810.5609.camel@twins> <20100527173218.GF2468@srcf.ucam.org> <1274981750.27810.5641.camel@twins> <20100527174140.GB3187@srcf.ucam.org> <1274982397.27810.5679.camel@twins> <20100527175258.GB3543@srcf.ucam.org> <1274982981.27810.5719.camel@twins> <20100527175920.GE3543@srcf.ucam.org> <1274983598.27810.5761.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1274983598.27810.5761.camel@twins> User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@srcf.ucam.org