Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757485AbZLFT7V (ORCPT ); Sun, 6 Dec 2009 14:59:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757269AbZLFT7T (ORCPT ); Sun, 6 Dec 2009 14:59:19 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:54135 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757224AbZLFT7S (ORCPT ); Sun, 6 Dec 2009 14:59:18 -0500 Date: Sun, 6 Dec 2009 11:58:44 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Arjan van de Ven cc: "Rafael J. Wysocki" , LKML , ACPI Devel Maling List , pm list , Alan Stern Subject: Re: [GIT PULL] PM updates for 2.6.33 In-Reply-To: <20091206113555.5a646713@infradead.org> Message-ID: References: <200912052216.19540.rjw@sisk.pl> <200912060055.36130.rjw@sisk.pl> <200912060254.10081.rjw@sisk.pl> <20091206113555.5a646713@infradead.org> 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: 1441 Lines: 38 On Sun, 6 Dec 2009, Arjan van de Ven wrote: > > in suspend, there's a PCI device (:1b) that does take some time, which > is the audio controller. The bulk of the time is in the serio driver > though.. That serio thing is disgusting. We had serious problems with the serial driver timeouts for boot-time optimizations too, didn't we? I assume that you don't even _use_ that serial port, do you? Or is it open for serial console logging or something? If it isn't even open, we shouldn't waste any time on the hardware. Your graph seems to say that serio1 shutdown is roughly from 29.40 to 29.85, ie almost half a second. That's just bogus. I don't see where it comes from, though. It looks like we have - pciserial_suspend_ports/serial_pnp_suspend -> serial8250_suspend_port -> uart_suspend_port -> (wait for tx_empty, but only for ASYNC_INITIALIZED, which shouldn't be true if it's closed, and should be limited to 30ms) uart_change_pm -> serial8250_pm and none of them look like they should take anywhere close to half a second. So I'm obviously missing something, and your chart didn't include the sleep/wakeup pairs. Linus -- 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/