From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yinghai Lu Subject: Re: [RFC PATCH 6/6] sparc64: use early_res and nobootmem Date: Wed, 10 Mar 2010 14:31:25 -0800 Message-ID: <4B981DBD.2060303@kernel.org> References: <4B981049.3040607@kernel.org> <20100310.133646.144946890.davem@davemloft.net> <4B9818CE.7090809@kernel.org> <20100310.141757.95833226.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from hera.kernel.org ([140.211.167.34]:46864 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757367Ab0CJWcj (ORCPT ); Wed, 10 Mar 2010 17:32:39 -0500 In-Reply-To: <20100310.141757.95833226.davem@davemloft.net> Sender: linux-arch-owner@vger.kernel.org List-ID: To: David Miller Cc: mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org On 03/10/2010 02:17 PM, David Miller wrote: > From: Yinghai Lu > Date: Wed, 10 Mar 2010 14:10:22 -0800 > >> On 03/10/2010 01:36 PM, David Miller wrote: >>> And LMB cannot fill this void with some minor modifications? >> >> early_res array could be increased automatically... >> >> could be something like: >> keep lmb.memory part, and use early_res for reserved parts... > > LMB has a reserved region. > > I still have yet to see any fundamental reason why LMB > cannot, all by itself, be used to solve this problem too. they are array based. 1. memmap is not changed after get it from firmware, 2. early_res at first is static array, later it will be relocated to another position if the array is not big enough. so arch only need to have it's own setup_memory_map, to fill fw_memmap according to FW, and later using find_fw_memmap_area and reserve_early all the way... later in mem_init to call free_all_memory_core_early instead. YH