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.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 B95C9C2D0E5 for ; Mon, 30 Mar 2020 17:51:21 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 936502073B for ; Mon, 30 Mar 2020 17:51:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hYTmG4TA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 936502073B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:In-Reply-To:MIME-Version: References:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BJwE1l/GEXgwgcp07TsByJPzJMTE2pyRwzaVWysKa78=; b=hYTmG4TAq0KoAs 9kLbqVH93ziVxQ8+0nMZomFExo1+WKYA206qjrTC5jrAQaLGmdyX+RCXa2I+oqC4uiMSWsvzT1QZ6 5ocKH3KmQTw4DeC/ukWOjQjclmp/2kUO9zUzJrR4Pt85ZLPqrP6PYKrcspGWwWQKn2SL4F1k4kI6Z 1cUIRHo3aFVjL4+YMpYTdG89loXaoyjcIrnYsgKr/zXLqkM2LZcOY8MfIfIMBWQnaZkCDVUsZ4tNh Hn7r7Ct2jlgVgpAOqLeYD6KyOZImxIG97qZeEICUGrtjeL5BJI3ikZJ5jmL20tf9o1dpXHszLUwDd CsXS1rawJtcvTIYYJVbg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jIyZD-0007l7-FR; Mon, 30 Mar 2020 17:51:19 +0000 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jIyZ9-0007kh-Sb for linux-arm-kernel@lists.infradead.org; Mon, 30 Mar 2020 17:51:17 +0000 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02UHY3tV073544 for ; Mon, 30 Mar 2020 13:51:14 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 3022f2k6p8-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Mar 2020 13:51:14 -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 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-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 adultscore=0 mlxscore=0 priorityscore=1501 bulkscore=0 spamscore=0 suspectscore=1 mlxlogscore=999 malwarescore=0 impostorscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300153 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200330_105116_050178_28D40A6C X-CRM114-Status: GOOD ( 37.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mmorana@amperecomputing.com, Catalin Marinas , Heiko Carstens , "open list:MEMORY MANAGEMENT" , Paul Mackerras , "H. Peter Anvin" , sparclinux@vger.kernel.org, Alexander Duyck , linux-s390@vger.kernel.org, Michael Ellerman , x86@kernel.org, Christian Borntraeger , Ingo Molnar , Hoan Tran , Benjamin Herrenschmidt , Pavel Tatashin , lho@amperecomputing.com, Vasily Gorbik , Vlastimil Babka , Will Deacon , Borislav Petkov , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Oscar Salvador , linux-kernel@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel