Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753462AbZLST7n (ORCPT ); Sat, 19 Dec 2009 14:59:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753330AbZLST7n (ORCPT ); Sat, 19 Dec 2009 14:59:43 -0500 Received: from mail-pw0-f42.google.com ([209.85.160.42]:64756 "EHLO mail-pw0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753313AbZLST7m (ORCPT ); Sat, 19 Dec 2009 14:59:42 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=gzdEkKHYfZQXllvZ71Ejy/81CxZAvMrYhd8T8SvnJGWcHOB3mH5CCa2fAleik0pzu2 ok8x6547kP2+q1cXuP3x5lUAjimQdaznB5hQKaLXsgQgr+gCsPVczgbB1llLI1Bt9JL5 D35obF6GZ9rOm0v9KCqXbG6eO0yfEochSAf2s= Date: Sat, 19 Dec 2009 11:59:35 -0800 From: Dmitry Torokhov To: "Rafael J. Wysocki" Cc: Linus Torvalds , 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) Message-ID: <20091219195935.GB4073@core.coreip.homeip.net> References: <200912160311.05915.rjw@sisk.pl> <20091216064025.GB2699@core.coreip.homeip.net> <200912182343.29190.rjw@sisk.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912182343.29190.rjw@sisk.pl> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4475 Lines: 98 On Fri, Dec 18, 2009 at 11:43:29PM +0100, Rafael J. Wysocki wrote: > On Wednesday 16 December 2009, Dmitry Torokhov wrote: > > On Wed, Dec 16, 2009 at 03:11:05AM +0100, Rafael J. Wysocki wrote: > > > On Tuesday 15 December 2009, Linus Torvalds wrote: > > > > > > > > On Tue, 15 Dec 2009, Rafael J. Wysocki wrote: > > > > > > > > > > > > Give a real example that matters. > > > > > > > > > > I'll try. Let -> denote child-parent relationships and assume dpm_list looks > > > > > like this: > > > > > > > > No. > > > > > > > > I mean something real - something like > > > > > > > > - if you run on a non-PC with two USB buses behind non-PCI controllers. > > > > > > > > - device xyz. > > > > > > > > > If this applies to _resume_ only, then I agree, but the Arjan's data clearly > > > > > show that serio devices take much more time to suspend than USB. > > > > > > > > I mean in general - something where you actually have hard data that some > > > > device really needs anythign more than my one-liner, and really _needs_ > > > > some complex infrastructure. > > > > > > > > Not "let's imagine a case like xyz". > > > > > > As I said I would, I made some measurements. > > > > > > I measured the total time of suspending and resuming devices as shown by the > > > code added by this patch: > > > http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=commitdiff_plain;h=c1b8fc0a8bff7707c10f31f3d26bfa88e18ccd94;hp=087dbf5f079f1b55cbd3964c9ce71268473d5b67 > > > on two boxes, HP nx6325 and MSI Wind U100 (hardware-wise they are quite > > > different and the HP was running 64-bit kernel and user space). > > > > > > I took four cases into consideration: > > > (1) synchronous suspend and resume (/sys/power/pm_async = 0) > > > (2) asynchronous suspend and resume as introduced by the async branch at: > > > http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=shortlog;h=refs/heads/async > > > (3) asynchronous suspend and resume like in (2), but with your one-liner setting > > > the power.async_suspend flag for PCI bridges on top > > > (4) asynchronous suspend and resume like in (2), but with an extra patch that > > > is appended on top > > > > > > For those tests I set power.async_suspend for all USB devices, all serio input > > > devices, the ACPI battery and the USB PCI controllers (to see the impact of the > > > one-liner, if any). > > > > > > I carried out 5 consecutive suspend-resume cycles (started from under X) on > > > each box in each case, and the raw data are here (all times in milliseconds): > > > http://www.sisk.pl/kernel/data/async-suspend.pdf > > > > > > The summarized data are below (the "big" numbers are averages and the +/- > > > numbers are standard deviations, all in milliseconds): > > > > > > HP nx6325 MSI Wind U100 > > > > > > sync suspend 1482 (+/- 40) 1180 (+/- 24) > > > sync resume 2955 (+/- 2) 3597 (+/- 25) > > > > > > async suspend 1553 (+/- 49) 1177 (+/- 32) > > > async resume 2692 (+/- 326) 3556 (+/- 33) > > > > > > async+one-liner suspend 1600 (+/- 39) 1212 (+/- 41) > > > async+one-liner resume 2692 (+/- 324) 3579 (+/- 24) > > > > > > async+extra suspend 1496 (+/- 37) 1217 (+/- 38) > > > async+extra resume 1859 (+/- 114) 1923 (+/- 35) > > > > > > So, in my opinion, with the above set of "async" devices, it doesn't > > > make sense to do async suspend at all, because the sync suspend is actually > > > the fastest on both machines. > > > > I think the async suspend is not asynchronous enough then - what kind of > > time do you get if you simply comment out call to psmouse_reset() in > > drivers/input/mouse/psmouse-base.c:psmouse_cleanup()? (Just for testing > > purposes only, I don't think we want to do that by default.) > > The problem apparently is that the i8042 suspend/resume is synchronous. > > Do you think it's safe to mark it as asynchronous? > Umm.. there lie dragons. There is an implicit relationship between i8042 and PNP/ACPI devices representing keyboard and mouse ports, and I am not sure how happy i8042 (and most importantly the BIOS) will be if they get shut down before i8042. Also there is EC which is in theory independent but in practice not so much. -- Dmitry -- 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/