From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.sgi.com [192.48.179.30]) by ozlabs.org (Postfix) with ESMTP id 07AC7B710D for ; Tue, 11 Jan 2011 06:21:03 +1100 (EST) Date: Mon, 10 Jan 2011 13:11:22 -0600 From: Robin Holt To: Nathan Fontenot Subject: Re: [PATCH 0/4] De-couple sysfs memory directories from memory sections Message-ID: <20110110191122.GN2912@sgi.com> References: <4D2B4B38.80102@austin.ibm.com> <20110110184416.GA18974@kroah.com> <4D2B543A.3070609@austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <4D2B543A.3070609@austin.ibm.com> Cc: Greg KH , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Robin Holt , linuxppc-dev@lists.ozlabs.org, KAMEZAWA Hiroyuki List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > >> The root of this issue is in sysfs directory creation. Every time > >> a directory is created a string compare is done against all sibling > >> directories to ensure we do not create duplicates. The list of > >> directory nodes in sysfs is kept as an unsorted list which results > >> in this being an exponentially longer operation as the number of > >> directories are created. > > > > Are you sure this is still an issue? I thought we solved this last > > kernel or so with a simple patch? > > I'll go back and look at this again. What I recall fixing is the symbolic linking from the node* to the memory section. In that case, we cached the most recent mem section and since they always were added sequentially, the cache saved a rescan. Of course, I could be remembering something completely unrelated. Robin