From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753570Ab1HARIz (ORCPT ); Mon, 1 Aug 2011 13:08:55 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:61159 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753008Ab1HARIw (ORCPT ); Mon, 1 Aug 2011 13:08:52 -0400 X-IronPort-AV: E=McAfee;i="5400,1158,6425"; a="107330864" Date: Mon, 1 Aug 2011 10:08:50 -0700 From: Larry Bassel To: Shaohua Li Cc: Larry Bassel , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: questions about memory hotplug Message-ID: <20110801170850.GB3466@labbmf-linux.qualcomm.com> References: <20110729221230.GA3466@labbmf-linux.qualcomm.com> <20110730093055.GA10672@sli10-conroe.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110730093055.GA10672@sli10-conroe.sh.intel.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30 Jul 11 17:30, Shaohua Li wrote: > On Sat, Jul 30, 2011 at 06:12:31AM +0800, Larry Bassel wrote: > > We want to handle the following 2 use cases we have on > > some of our (ARM) platforms: > > > > 1. A platform where part of the memory may be powered > > off. The location and size of this memory is not known > > until the kernel parses the memory tags (there aren't > > any non-standard tags used, but the memory layout and > > a memory bank size which is obtained from HW are used > > to figure out where and how large this memory is). All > > of this memory must either be on or off. For a given > > configuration the location of this memory can't be moved. > > > > 2. A (different) platform where part of the memory > > is occasionally needed as a large physically contiguous > > block, but usually is not (and then should be usable > > by the kernel as normal memory). When the memory is > > needed for the contiguous block, the pages in this > > range currently being used by the kernel will > > need to be migrated out. > > > > The size of this is known at compile time and can be > > placed at any reasonable place in memory (but should > > be SPARSEMEM section aligned -- its size may however > > not be a power of 2 and thus this memory could > > span more than one section). This memory will not be > > powered off, but must either be completely used for > > one purpose or the other. > > > > The size of memory in question for #1 is generally > > much larger than that of #2. > > > > Memory hotplug/hotremove (logical and physical for #1, > > only logical for #2) approximately solves these problems, > > but there is some functionality we need that AFAIK is > > not present: > > > > * The memory in #1 and #2 above must be in a movable > > zone so that the chance of migration is maximized. > > I'm familiar with the kernelcore= and movablecore= > > commandline options, but they don't do what is necessary > > here, because we need control on where the movable zone > > is formed as well as the size. Also the location and size > > of these special memory areas is not known until the > > kernel comes up (in #1 it is conceivable that the bootloader > > could locate the memory that can be powered on and off and > > pass it in via some commandline option, but AFAICT this won't > > work at all for #2). > > > > One could hack up find_zone_movable_pfns_for_nodes() presumably, > > but I wonder if there is an already existing way of doing > > this (or at least a clean extension to the current > > functionality that someone might suggest). > > > > Would CONFIG_ARCH_POPULATES_NODE_MAP help here? Does anyone > > use this? It doesn't seem to be in any defconfig or Kconfig > > on 3.0 (or earlier versions I've looked at). > > > > Perhaps CMA (which is not merged yet and AFAIK still has some > > issues on ARM) might handle #2 better than memory > > hotplug/hotremove. Or is there a better way to handle #2 > > than either CMA or memory hotplug? > is such memory always at the end of memory? if yes, such memory > can be added to MOVABLE_ZONE. In use case #1 yes, maybe not in #2 (we can arrange it to be at the end of memory, but then might waste memory as it may not be aligned on a SPARSEMEM section boundary and so would need to be padded). > or if such memory can be at the middle of memory, maybe we can add > a new mirgate type, the migrate type is movable but other type allocation > can't fallback into. > > Thanks, > Shaohua Larry > > -- > 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/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > Don't email: email@kvack.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 2B96790015F for ; Mon, 1 Aug 2011 13:08:53 -0400 (EDT) Date: Mon, 1 Aug 2011 10:08:50 -0700 From: Larry Bassel Subject: Re: questions about memory hotplug Message-ID: <20110801170850.GB3466@labbmf-linux.qualcomm.com> References: <20110729221230.GA3466@labbmf-linux.qualcomm.com> <20110730093055.GA10672@sli10-conroe.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110730093055.GA10672@sli10-conroe.sh.intel.com> Sender: owner-linux-mm@kvack.org List-ID: To: Shaohua Li Cc: Larry Bassel , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" On 30 Jul 11 17:30, Shaohua Li wrote: > On Sat, Jul 30, 2011 at 06:12:31AM +0800, Larry Bassel wrote: > > We want to handle the following 2 use cases we have on > > some of our (ARM) platforms: > > > > 1. A platform where part of the memory may be powered > > off. The location and size of this memory is not known > > until the kernel parses the memory tags (there aren't > > any non-standard tags used, but the memory layout and > > a memory bank size which is obtained from HW are used > > to figure out where and how large this memory is). All > > of this memory must either be on or off. For a given > > configuration the location of this memory can't be moved. > > > > 2. A (different) platform where part of the memory > > is occasionally needed as a large physically contiguous > > block, but usually is not (and then should be usable > > by the kernel as normal memory). When the memory is > > needed for the contiguous block, the pages in this > > range currently being used by the kernel will > > need to be migrated out. > > > > The size of this is known at compile time and can be > > placed at any reasonable place in memory (but should > > be SPARSEMEM section aligned -- its size may however > > not be a power of 2 and thus this memory could > > span more than one section). This memory will not be > > powered off, but must either be completely used for > > one purpose or the other. > > > > The size of memory in question for #1 is generally > > much larger than that of #2. > > > > Memory hotplug/hotremove (logical and physical for #1, > > only logical for #2) approximately solves these problems, > > but there is some functionality we need that AFAIK is > > not present: > > > > * The memory in #1 and #2 above must be in a movable > > zone so that the chance of migration is maximized. > > I'm familiar with the kernelcore= and movablecore= > > commandline options, but they don't do what is necessary > > here, because we need control on where the movable zone > > is formed as well as the size. Also the location and size > > of these special memory areas is not known until the > > kernel comes up (in #1 it is conceivable that the bootloader > > could locate the memory that can be powered on and off and > > pass it in via some commandline option, but AFAICT this won't > > work at all for #2). > > > > One could hack up find_zone_movable_pfns_for_nodes() presumably, > > but I wonder if there is an already existing way of doing > > this (or at least a clean extension to the current > > functionality that someone might suggest). > > > > Would CONFIG_ARCH_POPULATES_NODE_MAP help here? Does anyone > > use this? It doesn't seem to be in any defconfig or Kconfig > > on 3.0 (or earlier versions I've looked at). > > > > Perhaps CMA (which is not merged yet and AFAIK still has some > > issues on ARM) might handle #2 better than memory > > hotplug/hotremove. Or is there a better way to handle #2 > > than either CMA or memory hotplug? > is such memory always at the end of memory? if yes, such memory > can be added to MOVABLE_ZONE. In use case #1 yes, maybe not in #2 (we can arrange it to be at the end of memory, but then might waste memory as it may not be aligned on a SPARSEMEM section boundary and so would need to be padded). > or if such memory can be at the middle of memory, maybe we can add > a new mirgate type, the migrate type is movable but other type allocation > can't fallback into. > > Thanks, > Shaohua Larry > > -- > 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/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > Don't email: email@kvack.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: lbassel@codeaurora.org (Larry Bassel) Date: Mon, 1 Aug 2011 10:08:50 -0700 Subject: questions about memory hotplug In-Reply-To: <20110730093055.GA10672@sli10-conroe.sh.intel.com> References: <20110729221230.GA3466@labbmf-linux.qualcomm.com> <20110730093055.GA10672@sli10-conroe.sh.intel.com> Message-ID: <20110801170850.GB3466@labbmf-linux.qualcomm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 30 Jul 11 17:30, Shaohua Li wrote: > On Sat, Jul 30, 2011 at 06:12:31AM +0800, Larry Bassel wrote: > > We want to handle the following 2 use cases we have on > > some of our (ARM) platforms: > > > > 1. A platform where part of the memory may be powered > > off. The location and size of this memory is not known > > until the kernel parses the memory tags (there aren't > > any non-standard tags used, but the memory layout and > > a memory bank size which is obtained from HW are used > > to figure out where and how large this memory is). All > > of this memory must either be on or off. For a given > > configuration the location of this memory can't be moved. > > > > 2. A (different) platform where part of the memory > > is occasionally needed as a large physically contiguous > > block, but usually is not (and then should be usable > > by the kernel as normal memory). When the memory is > > needed for the contiguous block, the pages in this > > range currently being used by the kernel will > > need to be migrated out. > > > > The size of this is known at compile time and can be > > placed at any reasonable place in memory (but should > > be SPARSEMEM section aligned -- its size may however > > not be a power of 2 and thus this memory could > > span more than one section). This memory will not be > > powered off, but must either be completely used for > > one purpose or the other. > > > > The size of memory in question for #1 is generally > > much larger than that of #2. > > > > Memory hotplug/hotremove (logical and physical for #1, > > only logical for #2) approximately solves these problems, > > but there is some functionality we need that AFAIK is > > not present: > > > > * The memory in #1 and #2 above must be in a movable > > zone so that the chance of migration is maximized. > > I'm familiar with the kernelcore= and movablecore= > > commandline options, but they don't do what is necessary > > here, because we need control on where the movable zone > > is formed as well as the size. Also the location and size > > of these special memory areas is not known until the > > kernel comes up (in #1 it is conceivable that the bootloader > > could locate the memory that can be powered on and off and > > pass it in via some commandline option, but AFAICT this won't > > work at all for #2). > > > > One could hack up find_zone_movable_pfns_for_nodes() presumably, > > but I wonder if there is an already existing way of doing > > this (or at least a clean extension to the current > > functionality that someone might suggest). > > > > Would CONFIG_ARCH_POPULATES_NODE_MAP help here? Does anyone > > use this? It doesn't seem to be in any defconfig or Kconfig > > on 3.0 (or earlier versions I've looked at). > > > > Perhaps CMA (which is not merged yet and AFAIK still has some > > issues on ARM) might handle #2 better than memory > > hotplug/hotremove. Or is there a better way to handle #2 > > than either CMA or memory hotplug? > is such memory always at the end of memory? if yes, such memory > can be added to MOVABLE_ZONE. In use case #1 yes, maybe not in #2 (we can arrange it to be at the end of memory, but then might waste memory as it may not be aligned on a SPARSEMEM section boundary and so would need to be padded). > or if such memory can be at the middle of memory, maybe we can add > a new mirgate type, the migrate type is movable but other type allocation > can't fallback into. > > Thanks, > Shaohua Larry > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo at kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > Don't email: email at kvack.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.