Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754574AbZLQXcX (ORCPT ); Thu, 17 Dec 2009 18:32:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751264AbZLQXcU (ORCPT ); Thu, 17 Dec 2009 18:32:20 -0500 Received: from gate.crashing.org ([63.228.1.57]:49455 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751245AbZLQXcS (ORCPT ); Thu, 17 Dec 2009 18:32:18 -0500 Subject: Re: [GIT PULL] PM updates for 2.6.33 From: Benjamin Herrenschmidt To: Linus Torvalds Cc: Zhang Rui , Alan Stern , "Rafael J. Wysocki" , LKML , ACPI Devel Maling List , pm list , Arjan van de Ven In-Reply-To: References: <1260158279.27069.181.camel@rzhang1-desktop> Content-Type: text/plain; charset="UTF-8" Date: Fri, 18 Dec 2009 10:28:19 +1100 Message-ID: <1261092499.6682.44.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1330 Lines: 35 On Sun, 2009-12-06 at 22:15 -0800, Linus Torvalds wrote: > > The same is true of the prepare_suspend/suspend split I'm proposing: > I > suspect that for something like USB, it would make most sense to just > do > normal node suspend in prepare_suspend, which would do everything > asynchronously. Only USB hub devices would get involved at the later > 'suspend()' phase. Wasn't part of the goal with prepare_suspend() vs. suspend() to handle the problem of backing store vs the VM ? IE. Once any device potentially in the VM path is suspended, things like kmalloc() or gfp() can potentially stall until resume or did we address that recently ? Iirc, part of the idea behind prepare_* is that it's safe vs. the above. Now if you start suspending USB devices at prepare() then you break that assumption since those could be mass storage with dirty mmap'ed pages on them. Now, I'm all for fixing it at the VM/allocator level (if we didn't already) turning pretty much everything into NO_IO once we start suspending devices but that's a whole different matter :-) Cheers, Ben. -- 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/