From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3sf9kJ3Z9QzDsgk for ; Wed, 21 Sep 2016 17:10:15 +1000 (AEST) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8L78VQX048637 for ; Wed, 21 Sep 2016 03:10:14 -0400 Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mx0a-001b2d01.pphosted.com with ESMTP id 25k6ckjetk-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Sep 2016 03:10:13 -0400 Received: from localhost by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Sep 2016 01:10:11 -0600 From: "Aneesh Kumar K.V" To: Reza Arbab Cc: Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Rob Herring , Frank Rowand , Jonathan Corbet , Andrew Morton , Bharata B Rao , Nathan Fontenot , Stewart Smith , Alistair Popple , Balbir Singh , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, devicetree@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc In-Reply-To: <20160921054500.lrqktzjqjhuzewqg@arbab-laptop> References: <1473883618-14998-1-git-send-email-arbab@linux.vnet.ibm.com> <1473883618-14998-4-git-send-email-arbab@linux.vnet.ibm.com> <87h99cxv00.fsf@linux.vnet.ibm.com> <20160921054500.lrqktzjqjhuzewqg@arbab-laptop> Date: Wed, 21 Sep 2016 12:39:51 +0530 MIME-Version: 1.0 Content-Type: text/plain Message-Id: <87oa3hwwxs.fsf@linux.vnet.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reza Arbab writes: > On Mon, Sep 19, 2016 at 11:59:35AM +0530, Aneesh Kumar K.V wrote: >>Movable node also does. >> memblock_set_bottom_up(true); >>What is the impact of that. Do we need changes equivalent to that ? Also >>where are we marking the nodes which can be hotplugged, ie where do we >>do memblock_mark_hotplug() ? > > These are related to the mechanism x86 uses to create movable nodes at > boot. The SRAT is parsed to mark any hotplug memory. That marking is > used later when initializing ZONE_MOVABLE for each node. [1] > > The bottom-up allocation is due to a timing issue [2]. There is a window > where kernel memory may be allocated before the SRAT is parsed. Any > bottom-up allocations done during that time will likely be in the same > (nonmovable) node as the kernel image. > > On power, I don't think we have a heuristic equivalent to that SRAT > memory hotplug info. So, we'll be limited to dynamically adding movable > nodes after boot. > > 1. http://events.linuxfoundation.org/sites/events/files/lcjp13_chen.pdf > 2. commit 79442ed189ac ("mm/memblock.c: introduce bottom-up allocation > mode") > What I was checking was how will one mark a node movable in ppc64 ? I don't see ppc64 code doing the equivalent of memblock_mark_hotplug(). So when you say "Onlining memory into ZONE_MOVABLE requires CONFIG_MOVABLE_NODE" where is that restriction ?. IIUC, should_add_memory_movable() will only return ZONE_MOVABLE only if it is non empty and MOVABLE_NODE will create a ZONE_MOVABLE zone by default only if it finds a memblock marked hotpluggable. So wondering if we are not calling memblock_mark_hotplug() how is it working. Or am I missing something ? -aneesh From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K.V" Subject: Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc Date: Wed, 21 Sep 2016 12:39:51 +0530 Message-ID: <87oa3hwwxs.fsf@linux.vnet.ibm.com> References: <1473883618-14998-1-git-send-email-arbab@linux.vnet.ibm.com> <1473883618-14998-4-git-send-email-arbab@linux.vnet.ibm.com> <87h99cxv00.fsf@linux.vnet.ibm.com> <20160921054500.lrqktzjqjhuzewqg@arbab-laptop> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20160921054500.lrqktzjqjhuzewqg@arbab-laptop> Sender: owner-linux-mm@kvack.org To: Reza Arbab Cc: Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Rob Herring , Frank Rowand , Jonathan Corbet , Andrew Morton , Bharata B Rao , Nathan Fontenot , Stewart Smith , Alistair Popple , Balbir Singh , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, devicetree@vger.kernel.org, linux-mm@kvack.org List-Id: devicetree@vger.kernel.org Reza Arbab writes: > On Mon, Sep 19, 2016 at 11:59:35AM +0530, Aneesh Kumar K.V wrote: >>Movable node also does. >> memblock_set_bottom_up(true); >>What is the impact of that. Do we need changes equivalent to that ? Also >>where are we marking the nodes which can be hotplugged, ie where do we >>do memblock_mark_hotplug() ? > > These are related to the mechanism x86 uses to create movable nodes at > boot. The SRAT is parsed to mark any hotplug memory. That marking is > used later when initializing ZONE_MOVABLE for each node. [1] > > The bottom-up allocation is due to a timing issue [2]. There is a window > where kernel memory may be allocated before the SRAT is parsed. Any > bottom-up allocations done during that time will likely be in the same > (nonmovable) node as the kernel image. > > On power, I don't think we have a heuristic equivalent to that SRAT > memory hotplug info. So, we'll be limited to dynamically adding movable > nodes after boot. > > 1. http://events.linuxfoundation.org/sites/events/files/lcjp13_chen.pdf > 2. commit 79442ed189ac ("mm/memblock.c: introduce bottom-up allocation > mode") > What I was checking was how will one mark a node movable in ppc64 ? I don't see ppc64 code doing the equivalent of memblock_mark_hotplug(). So when you say "Onlining memory into ZONE_MOVABLE requires CONFIG_MOVABLE_NODE" where is that restriction ?. IIUC, should_add_memory_movable() will only return ZONE_MOVABLE only if it is non empty and MOVABLE_NODE will create a ZONE_MOVABLE zone by default only if it finds a memblock marked hotpluggable. So wondering if we are not calling memblock_mark_hotplug() how is it working. Or am I missing something ? -aneesh -- 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