From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11615C43331 for ; Mon, 30 Mar 2020 17:51:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D87202073B for ; Mon, 30 Mar 2020 17:51:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730288AbgC3RvQ (ORCPT ); Mon, 30 Mar 2020 13:51:16 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38846 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728075AbgC3RvQ (ORCPT ); Mon, 30 Mar 2020 13:51:16 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02UHWh5K127525 for ; Mon, 30 Mar 2020 13:51:15 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 3022qxaxg4-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Mar 2020 13:51:15 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Mar 2020 18:50:59 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 30 Mar 2020 18:50:53 +0100 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 02UHp4g862914630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Mar 2020 17:51:05 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DB44AA405C; Mon, 30 Mar 2020 17:51:04 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 63487A4054; Mon, 30 Mar 2020 17:51:02 +0000 (GMT) Received: from linux.ibm.com (unknown [9.148.206.230]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 30 Mar 2020 17:51:02 +0000 (GMT) Date: Mon, 30 Mar 2020 20:51:00 +0300 From: Mike Rapoport To: Michal Hocko Cc: Hoan Tran , Catalin Marinas , Will Deacon , Andrew Morton , Vlastimil Babka , Oscar Salvador , Pavel Tatashin , Alexander Duyck , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "David S. Miller" , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , "open list:MEMORY MANAGEMENT" , linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, lho@amperecomputing.com, mmorana@amperecomputing.com Subject: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA References: <1585420282-25630-1-git-send-email-Hoan@os.amperecomputing.com> <20200330074246.GA14243@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200330074246.GA14243@dhcp22.suse.cz> X-TM-AS-GCONF: 00 x-cbid: 20033017-0020-0000-0000-000003BE6645 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 20033017-0021-0000-0000-00002217033F Message-Id: <20200330175100.GD30942@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-03-30_07:2020-03-30,2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 phishscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 impostorscore=0 suspectscore=1 adultscore=0 clxscore=1015 bulkscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300154 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 30, 2020 at 09:42:46AM +0200, Michal Hocko wrote: > On Sat 28-03-20 11:31:17, Hoan Tran wrote: > > In NUMA layout which nodes have memory ranges that span across other nodes, > > the mm driver can detect the memory node id incorrectly. > > > > For example, with layout below > > Node 0 address: 0000 xxxx 0000 xxxx > > Node 1 address: xxxx 1111 xxxx 1111 > > > > Note: > > - Memory from low to high > > - 0/1: Node id > > - x: Invalid memory of a node > > > > When mm probes the memory map, without CONFIG_NODES_SPAN_OTHER_NODES > > config, mm only checks the memory validity but not the node id. > > Because of that, Node 1 also detects the memory from node 0 as below > > when it scans from the start address to the end address of node 1. > > > > Node 0 address: 0000 xxxx xxxx xxxx > > Node 1 address: xxxx 1111 1111 1111 > > > > This layout could occur on any architecture. Most of them enables > > this config by default with CONFIG_NUMA. This patch, by default, enables > > CONFIG_NODES_SPAN_OTHER_NODES or uses early_pfn_in_nid() for NUMA. > > I am not opposed to this at all. It reduces the config space and that is > a good thing on its own. The history has shown that meory layout might > be really wild wrt NUMA. The config is only used for early_pfn_in_nid > which is clearly an overkill. > > Your description doesn't really explain why this is safe though. The > history of this config is somehow messy, though. Mike has tried > to remove it a94b3ab7eab4 ("[PATCH] mm: remove arch independent > NODES_SPAN_OTHER_NODES") just to be reintroduced by 7516795739bd > ("[PATCH] Reintroduce NODES_SPAN_OTHER_NODES for powerpc") without any > reasoning what so ever. This doesn't make it really easy see whether > reasons for reintroduction are still there. Maybe there are some subtle > dependencies. I do not see any TBH but that might be burried deep in an > arch specific code. I've looked at this a bit more and it seems that the check for early_pfn_in_nid() in memmap_init_zone() can be simply removed. The commits you've mentioned were way before the addition of HAVE_MEMBLOCK_NODE_MAP and the whole infrastructure that calculates zone sizes and boundaries based on the memblock node map. So, the memmap_init_zone() is called when zone boundaries are already within a node. I don't have access to machines with memory layout that required this check at the first place, so if anybody who does could test the change below on such machine it would be great. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 3c4eb750a199..6d3eb0901864 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5908,10 +5908,6 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, pfn = next_pfn(pfn); continue; } - if (!early_pfn_in_nid(pfn, nid)) { - pfn++; - continue; - } if (overlap_memmap_init(zone, &pfn)) continue; if (defer_init(nid, pfn, end_pfn)) > > v3: > > * Revise the patch description > > > > V2: > > * Revise the patch description > > > > Hoan Tran (5): > > mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA > > powerpc: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES > > x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES > > sparc: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES > > s390: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES > > > > arch/powerpc/Kconfig | 9 --------- > > arch/s390/Kconfig | 8 -------- > > arch/sparc/Kconfig | 9 --------- > > arch/x86/Kconfig | 9 --------- > > mm/page_alloc.c | 2 +- > > 5 files changed, 1 insertion(+), 36 deletions(-) > > > > -- > > 1.8.3.1 > > > > -- > Michal Hocko > SUSE Labs -- Sincerely yours, Mike.