Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754740AbZLTMv0 (ORCPT ); Sun, 20 Dec 2009 07:51:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754479AbZLTMvX (ORCPT ); Sun, 20 Dec 2009 07:51:23 -0500 Received: from ogre.sisk.pl ([217.79.144.158]:36859 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753822AbZLTMvW (ORCPT ); Sun, 20 Dec 2009 07:51:22 -0500 From: "Rafael J. Wysocki" To: Alan Stern Subject: Re: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems) Date: Sun, 20 Dec 2009 13:52:07 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.32-rjw; KDE/4.3.3; x86_64; ; ) Cc: Linus Torvalds , Dmitry Torokhov , Zhang Rui , LKML , ACPI Devel Maling List , pm list References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912201352.07689.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1553 Lines: 32 On Sunday 20 December 2009, Alan Stern wrote: > On Sun, 20 Dec 2009, Rafael J. Wysocki wrote: > > > So, seriously, do you think it makes sense to do asynchronous suspend at all? > > I'm asking, because we're likely to get into troubles like this during suspend > > for other kinds of devices too and without resolving them we won't get any > > significant speedup from asynchronous suspend. > > > > That said, to me it's definitely worth doing asynchronous resume with the > > "start asynch threads upfront" modification, as the results of the tests show > > that quite clearly. I hope you agree. > > It's too early to come to this sort of conclusion (i.e., that suspend > and resume react very differently to an asynchronous approach). Unless > you have some definite _reason_ for thinking that resume will benefit > more than suspend, you shouldn't try to generalize so much from tests > on only two systems. In fact I have one reason. Namely, the things that drivers do on suspend and resume are evidently quite different and on these two systems I was able to test they apparently took different amounts of time to complete. The very fact that on both systems resume is substantially longer than suspend, even if all devices are suspended and resumed synchronously, is quite interesting. Rafael -- 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/