Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758046AbZLNWmT (ORCPT ); Mon, 14 Dec 2009 17:42:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756723AbZLNWmP (ORCPT ); Mon, 14 Dec 2009 17:42:15 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:35032 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754805AbZLNWmN (ORCPT ); Mon, 14 Dec 2009 17:42:13 -0500 Date: Mon, 14 Dec 2009 14:41:41 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: "Rafael J. Wysocki" cc: Alan Stern , Zhang Rui , LKML , ACPI Devel Maling List , pm list Subject: Re: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems) In-Reply-To: <200912142311.31658.rjw@sisk.pl> Message-ID: References: <200912122334.08367.rjw@sisk.pl> <200912142311.31658.rjw@sisk.pl> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1978 Lines: 61 On Mon, 14 Dec 2009, Rafael J. Wysocki wrote: > > OK, what about a two-pass approach in which the first pass only inits the > completions and starts async threads for leaf "async" devices? I think leaf > devices are most likely to take much time to suspend, so this will give us > a chance to save quite some time. Why? Really. Again, stop making it harder than it needs to be. Why do you make up these crazy schemes that are way more complex than they need to be? Here's an untested one-liner that has a 10-line comment. I agree it is ugly, but it is ugly exactly because the generic device layer _forces_ us to wait for children even when we don't want to. With this, that unnecessary wait is now done asynchronously. I'd rather do it some other way - perhaps having an explicit flag that says "don't wait for children because I'm not going to suspend myself until 'suspend_late' _anyway_". But at least this is _simple_. Linus --- drivers/pci/probe.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 98ffb2d..4e0ad7b 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -437,6 +437,17 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent, } bridge->subordinate = child; + /* + * We don't really suspend PCI buses asyncronously. + * + * However, since we don't actually suspend them at all until + * the late phase, we might as well lie to the device layer + * and it to do our no-op not-suspend asynchronously, so that + * we end up not synchronizing with any of our child devices + * that might want to be asynchronous. + */ + bridge->dev.power.async_suspend = 1; + return child; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/