Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754577Ab2K2PyT (ORCPT ); Thu, 29 Nov 2012 10:54:19 -0500 Received: from mail-pb0-f46.google.com ([209.85.160.46]:39161 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751336Ab2K2PyS (ORCPT ); Thu, 29 Nov 2012 10:54:18 -0500 Message-ID: <50B784F9.4030105@gmail.com> Date: Thu, 29 Nov 2012 23:53:29 +0800 From: Jiang Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Yasuaki Ishimatsu CC: "Luck, Tony" , Jiang Liu , Tang Chen , "hpa@zytor.com" , "akpm@linux-foundation.org" , "rob@landley.net" , "laijs@cn.fujitsu.com" , "wency@cn.fujitsu.com" , "linfeng@cn.fujitsu.com" , "yinghai@kernel.org" , "kosaki.motohiro@jp.fujitsu.com" , "minchan.kim@gmail.com" , "mgorman@suse.de" , "rientjes@google.com" , "rusty@rustcorp.com.au" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-doc@vger.kernel.org" , Len Brown , "Wang, Frank" Subject: Re: [PATCH v2 0/5] Add movablecore_map boot option References: <1353667445-7593-1-git-send-email-tangchen@cn.fujitsu.com> <50B5CFAE.80103@huawei.com> <3908561D78D1C84285E8C5FCA982C28F1C95EDCE@ORSMSX108.amr.corp.intel.com> <50B73B22.90500@jp.fujitsu.com> In-Reply-To: <50B73B22.90500@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2730 Lines: 74 Hi Yasuaki, Forgot to mention that I have no objection to this patchset. I think it's a good start point, but we still need to improve usabilities of memory hotplug by passing platform specific information from BIOS. And mechanism provided by this patchset will/may be used to improve usabilities too. Regards! Gerry On 11/29/2012 06:38 PM, Yasuaki Ishimatsu wrote: > Hi Tony, > > 2012/11/29 6:34, Luck, Tony wrote: >>> 1. use firmware information >>> According to ACPI spec 5.0, SRAT table has memory affinity structure >>> and the structure has Hot Pluggable Filed. See "5.2.16.2 Memory >>> Affinity Structure". If we use the information, we might be able to >>> specify movable memory by firmware. For example, if Hot Pluggable >>> Filed is enabled, Linux sets the memory as movable memory. >>> >>> 2. use boot option >>> This is our proposal. New boot option can specify memory range to use >>> as movable memory. >> >> Isn't this just moving the work to the user? To pick good values for the > > Yes. > >> movable areas, they need to know how the memory lines up across >> node boundaries ... because they need to make sure to allow some >> non-movable memory allocations on each node so that the kernel can >> take advantage of node locality. > > There is no problem. > Linux has already two boot options, kernelcore= and movablecore=. > So if we use them, non-movable memory is divided into each node evenly. > > But there is no way to specify a node used as movable currently. So > we proposed the new boot option. > >> So the user would have to read at least the SRAT table, and perhaps >> more, to figure out what to provide as arguments. >> > >> Since this is going to be used on a dynamic system where nodes might >> be added an removed - the right values for these arguments might >> change from one boot to the next. So even if the user gets them right >> on day 1, a month later when a new node has been added, or a broken >> node removed the values would be stale. > > I don't think so. Even if we hot add/remove node, the memory range of > each memory device is not changed. So we don't need to change the boot > option. > > Thanks, > Yasuaki Ishimatsu > >> >> -Tony >> > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/