From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753353Ab0AKMnr (ORCPT ); Mon, 11 Jan 2010 07:43:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753026Ab0AKMnq (ORCPT ); Mon, 11 Jan 2010 07:43:46 -0500 Received: from mga11.intel.com ([192.55.52.93]:62316 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752209Ab0AKMnq (ORCPT ); Mon, 11 Jan 2010 07:43:46 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,253,1262592000"; d="scan'208";a="763134688" Date: Mon, 11 Jan 2010 20:43:03 +0800 From: Wu Fengguang To: "Zheng, Shaohui" Cc: "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "ak@linux.intel.com" , "y-goto@jp.fujitsu.com" , Dave Hansen , "x86@kernel.org" , KAMEZAWA Hiroyuki Subject: Re: [PATCH - resend] Memory-Hotplug: Fix the bug on interface /dev/mem for 64-bit kernel(v1) Message-ID: <20100111124303.GA21408@localhost> References: <20100108124851.GB6153@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > + /* if add to low memory, update max_low_pfn */ > > + if (unlikely(start_pfn < limit_low_pfn)) { > > + if (end_pfn <= limit_low_pfn) > > + max_low_pfn = end_pfn; > > + else > > + max_low_pfn = limit_low_pfn; > > X86_64 actually always set max_low_pfn=max_pfn, in setup_arch(): > [Zheng, Shaohui] there should be some misunderstanding, I read the > code carefully, if the total memory is under 4G, it always > max_low_pfn=max_pfn. If the total memory is larger than 4G, > max_low_pfn means the end of low ram. It set > max_low_pfn = e820_end_of_low_ram_pfn();. The above line is very misleading.. In setup_arch(), it will be overrode by the following block. > 899 #ifdef CONFIG_X86_64 > 900 if (max_pfn > max_low_pfn) { > 901 max_pfn_mapped = init_memory_mapping(1UL<<32, > 902 max_pfn< 903 /* can we preseve max_low_pfn ?*/ > 904 max_low_pfn = max_pfn; > 905 } > 906 #endif Thanks, Fengguang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with SMTP id 20A176B006A for ; Mon, 11 Jan 2010 07:43:47 -0500 (EST) Date: Mon, 11 Jan 2010 20:43:03 +0800 From: Wu Fengguang Subject: Re: [PATCH - resend] Memory-Hotplug: Fix the bug on interface /dev/mem for 64-bit kernel(v1) Message-ID: <20100111124303.GA21408@localhost> References: <20100108124851.GB6153@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: "Zheng, Shaohui" Cc: "linux-mm@kvack.org" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "ak@linux.intel.com" , "y-goto@jp.fujitsu.com" , Dave Hansen , "x86@kernel.org" , KAMEZAWA Hiroyuki List-ID: > > + /* if add to low memory, update max_low_pfn */ > > + if (unlikely(start_pfn < limit_low_pfn)) { > > + if (end_pfn <= limit_low_pfn) > > + max_low_pfn = end_pfn; > > + else > > + max_low_pfn = limit_low_pfn; > > X86_64 actually always set max_low_pfn=max_pfn, in setup_arch(): > [Zheng, Shaohui] there should be some misunderstanding, I read the > code carefully, if the total memory is under 4G, it always > max_low_pfn=max_pfn. If the total memory is larger than 4G, > max_low_pfn means the end of low ram. It set > max_low_pfn = e820_end_of_low_ram_pfn();. The above line is very misleading.. In setup_arch(), it will be overrode by the following block. > 899 #ifdef CONFIG_X86_64 > 900 if (max_pfn > max_low_pfn) { > 901 max_pfn_mapped = init_memory_mapping(1UL<<32, > 902 max_pfn< 903 /* can we preseve max_low_pfn ?*/ > 904 max_low_pfn = max_pfn; > 905 } > 906 #endif Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org