From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by ozlabs.org (Postfix) with ESMTP id E40DB679E0 for ; Tue, 22 Aug 2006 04:52:41 +1000 (EST) Received: by nf-out-0910.google.com with SMTP id c2so2109666nfe for ; Mon, 21 Aug 2006 11:52:39 -0700 (PDT) Message-ID: Date: Mon, 21 Aug 2006 11:52:39 -0700 From: "Keith Mannthey" To: "Mel Gorman" Subject: Re: [PATCH 0/6] Sizing zones and holes in an architecture independent manner V9 In-Reply-To: <20060821134518.22179.46355.sendpatchset@skynet.skynet.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed References: <20060821134518.22179.46355.sendpatchset@skynet.skynet.ie> Cc: akpm@osdl.org, tony.luck@intel.com, linuxppc-dev@ozlabs.org, ak@suse.de, bob.picco@hp.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 8/21/06, Mel Gorman wrote: > This is V9 of the patchset to size zones and memory holes in an > architecture-independent manner. It booted successfully on 5 different > machines (arches were x86, x86_64, ppc64 and ia64) in a number of different > configurations and successfully built a kernel. If it fails on any machine, > booting with loglevel=8 and the console log should tell me what went wrong. > I am wondering why this new api didn't cleanup the pfn_to_nid code path as well. Arches are left to still keep another set of nid-start-end info around. We are sending info like add_active_range(unsigned int nid, unsigned long start_pfn, unsigned long end_pfn) With this info making a common pnf_to_nid seems to be of intrest so we don't have to keep redundant information in both generic and arch specific data structures. Are you intending the hot-add memory code path to call add_active_range or ??? Thanks, Keith