From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753793Ab2K1KKX (ORCPT ); Wed, 28 Nov 2012 05:10:23 -0500 Received: from hydra.sisk.pl ([212.160.235.94]:35053 "EHLO hydra.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752437Ab2K1KKV (ORCPT ); Wed, 28 Nov 2012 05:10:21 -0500 From: "Rafael J. Wysocki" To: Ming Lei Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Alan Stern , Oliver Neukum , Minchan Kim , Greg Kroah-Hartman , Jens Axboe , "David S. Miller" , Andrew Morton , netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v6 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio() Date: Wed, 28 Nov 2012 11:15:05 +0100 Message-ID: <2662154.Tcp7v84XkT@vostro.rjw.lan> User-Agent: KMail/4.9.3 (Linux/3.7.0-rc7; KDE/4.9.3; x86_64; ; ) In-Reply-To: References: <1353761958-12810-1-git-send-email-ming.lei@canonical.com> <1408044.6czCGhbHJH@vostro.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, November 28, 2012 05:47:18 PM Ming Lei wrote: > On Wed, Nov 28, 2012 at 5:29 PM, Rafael J. Wysocki wrote: > > > > But it doesn't have to walk the children. Moreover, with counters it only > > Yeah, I got it, it is the advantage of counter, but with extra 'int' > field introduced > in 'struct device'. > > > needs to walk the whole path if all devices in it need to be updated. For > > example, if you call pm_runtime_set_memalloc_noio(dev, true) for a device > > whose parent's counter is greater than zero already, you don't need to > > walk the path above the parent. > > We still can do it with the flag only, pm_runtime_set_memalloc_noio(dev, true) > can return immediately if one parent or the 'dev' flag is true. > > But considered that the pm_runtime_set_memalloc_noio(dev, false) is only > called in a very infrequent path(network/block device->remove()), looks the > introduced cost isn't worthy of the obtained advantage. > > So could you accept not introducing counter? and I will update with the > above improvement you suggested. Well, please see my other message I sent a while ago. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.