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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 472A1C73C6D for ; Wed, 10 Jul 2019 05:59:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 29B1E20838 for ; Wed, 10 Jul 2019 05:59:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726991AbfGJF7M (ORCPT ); Wed, 10 Jul 2019 01:59:12 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:46746 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725791AbfGJF7M (ORCPT ); Wed, 10 Jul 2019 01:59:12 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hl5cV-0004bB-Pv; Wed, 10 Jul 2019 07:58:23 +0200 Date: Wed, 10 Jul 2019 07:58:21 +0200 (CEST) From: Thomas Gleixner To: Hoan Tran OS cc: Catalin Marinas , Will Deacon , Andrew Morton , Michal Hocko , Vlastimil Babka , Oscar Salvador , Pavel Tatashin , Mike Rapoport , Alexander Duyck , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , 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" , Open Source Submission Subject: Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES In-Reply-To: <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> Message-ID: References: <1561501810-25163-1-git-send-email-Hoan@os.amperecomputing.com> <1561501810-25163-4-git-send-email-Hoan@os.amperecomputing.com> <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hoan, On Wed, 10 Jul 2019, Hoan Tran OS wrote: > On 6/25/19 3:45 PM, Thomas Gleixner wrote: > > On Tue, 25 Jun 2019, Hoan Tran OS wrote: > >> @@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA > >> ---help--- > >> Enable ACPI SRAT based node topology detection. > >> > >> -# Some NUMA nodes have memory ranges that span > >> -# other nodes. Even though a pfn is valid and > >> -# between a node's start and end pfns, it may not > >> -# reside on that node. See memmap_init_zone() > >> -# for details. > >> -config NODES_SPAN_OTHER_NODES > >> - def_bool y > >> - depends on X86_64_ACPI_NUMA > > > > the changelog does not mention that this lifts the dependency on > > X86_64_ACPI_NUMA and therefore enables that functionality for anything > > which has NUMA enabled including 32bit. > > > > I think this config is used for a NUMA layout which NUMA nodes addresses > are spanned to other nodes. I think 32bit NUMA also have the same issue > with that layout. Please correct me if I'm wrong. I'm not saying you're wrong, but it's your duty to provide the analysis why this is correct for everything which has NUMA enabled. > > The core mm change gives no helpful information either. You just copied the > > above comment text from some random Kconfig. > > Yes, as it's a correct comment and is used at multiple places. Well it maybe correct in terms of explaining what this is about, it still does not explain why this is needed by default on everything which has NUMA enabled. Thanks, tglx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Galois.linutronix.de ([193.142.43.55]:46746 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725791AbfGJF7M (ORCPT ); Wed, 10 Jul 2019 01:59:12 -0400 Date: Wed, 10 Jul 2019 07:58:21 +0200 (CEST) From: Thomas Gleixner Subject: Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES In-Reply-To: <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> Message-ID: References: <1561501810-25163-1-git-send-email-Hoan@os.amperecomputing.com> <1561501810-25163-4-git-send-email-Hoan@os.amperecomputing.com> <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-s390-owner@vger.kernel.org List-ID: To: Hoan Tran OS Cc: Catalin Marinas , Will Deacon , Andrew Morton , Michal Hocko , Vlastimil Babka , Oscar Salvador , Pavel Tatashin , Mike Rapoport , Alexander Duyck , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , 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" , Open Source Submission Hoan, On Wed, 10 Jul 2019, Hoan Tran OS wrote: > On 6/25/19 3:45 PM, Thomas Gleixner wrote: > > On Tue, 25 Jun 2019, Hoan Tran OS wrote: > >> @@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA > >> ---help--- > >> Enable ACPI SRAT based node topology detection. > >> > >> -# Some NUMA nodes have memory ranges that span > >> -# other nodes. Even though a pfn is valid and > >> -# between a node's start and end pfns, it may not > >> -# reside on that node. See memmap_init_zone() > >> -# for details. > >> -config NODES_SPAN_OTHER_NODES > >> - def_bool y > >> - depends on X86_64_ACPI_NUMA > > > > the changelog does not mention that this lifts the dependency on > > X86_64_ACPI_NUMA and therefore enables that functionality for anything > > which has NUMA enabled including 32bit. > > > > I think this config is used for a NUMA layout which NUMA nodes addresses > are spanned to other nodes. I think 32bit NUMA also have the same issue > with that layout. Please correct me if I'm wrong. I'm not saying you're wrong, but it's your duty to provide the analysis why this is correct for everything which has NUMA enabled. > > The core mm change gives no helpful information either. You just copied the > > above comment text from some random Kconfig. > > Yes, as it's a correct comment and is used at multiple places. Well it maybe correct in terms of explaining what this is about, it still does not explain why this is needed by default on everything which has NUMA enabled. Thanks, tglx From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Date: Wed, 10 Jul 2019 05:58:21 +0000 Subject: Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES Message-Id: List-Id: References: <1561501810-25163-1-git-send-email-Hoan@os.amperecomputing.com> <1561501810-25163-4-git-send-email-Hoan@os.amperecomputing.com> <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> In-Reply-To: <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hoan Tran OS Cc: Michal Hocko , 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" , Mike Rapoport , Christian Borntraeger , Ingo Molnar , Vlastimil Babka , Benjamin Herrenschmidt , Open Source Submission , Pavel Tatashin , Vasily Gorbik , Will Deacon , Borislav Petkov , "linux-arm-kernel@lists.infradead.org" , Oscar Salvador , "linux-kernel@vger.kernel.org" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , "David S . Miller" Hoan, On Wed, 10 Jul 2019, Hoan Tran OS wrote: > On 6/25/19 3:45 PM, Thomas Gleixner wrote: > > On Tue, 25 Jun 2019, Hoan Tran OS wrote: > >> @@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA > >> ---help--- > >> Enable ACPI SRAT based node topology detection. > >> > >> -# Some NUMA nodes have memory ranges that span > >> -# other nodes. Even though a pfn is valid and > >> -# between a node's start and end pfns, it may not > >> -# reside on that node. See memmap_init_zone() > >> -# for details. > >> -config NODES_SPAN_OTHER_NODES > >> - def_bool y > >> - depends on X86_64_ACPI_NUMA > > > > the changelog does not mention that this lifts the dependency on > > X86_64_ACPI_NUMA and therefore enables that functionality for anything > > which has NUMA enabled including 32bit. > > > > I think this config is used for a NUMA layout which NUMA nodes addresses > are spanned to other nodes. I think 32bit NUMA also have the same issue > with that layout. Please correct me if I'm wrong. I'm not saying you're wrong, but it's your duty to provide the analysis why this is correct for everything which has NUMA enabled. > > The core mm change gives no helpful information either. You just copied the > > above comment text from some random Kconfig. > > Yes, as it's a correct comment and is used at multiple places. Well it maybe correct in terms of explaining what this is about, it still does not explain why this is needed by default on everything which has NUMA enabled. Thanks, tglx 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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 0E2B9C73C6D for ; Wed, 10 Jul 2019 05:59:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9357F20838 for ; Wed, 10 Jul 2019 05:59:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9357F20838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CEDA38E0068; Wed, 10 Jul 2019 01:59:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9E448E0032; Wed, 10 Jul 2019 01:59:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8C2B8E0068; Wed, 10 Jul 2019 01:59:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by kanga.kvack.org (Postfix) with ESMTP id 569838E0032 for ; Wed, 10 Jul 2019 01:59:03 -0400 (EDT) Received: by mail-lj1-f197.google.com with SMTP id m2so289054ljj.0 for ; Tue, 09 Jul 2019 22:59:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:subject:in-reply-to:message-id:references:user-agent :mime-version; bh=PDwHUB/U1Dx9d92PPEJemltmsVvg53siDRKnpPtq0As=; b=TMeHz1vZ07dJ3LUsF+Hi3bMPAR+QbusKEk4gikIK4BgW8R8mJfQHPRi+4DfqMhFYdE zR9kkUFEJTdBjXT/ITYeJxU/yF4FtxJezBsEssfkhwzLtzpxjpS0WH3OJ8mGdd2bT9t/ tAt8o/toAjlmmqWHD3j2EK/8meqMNFMhexEVDX11scn5jsKDqYD/DWquVidCDmdIBbuW ND6Dti8vUQ89GK/pjwoXZsDhJ+duDd2/9pTtp9odh5UNccjkkoZR9IRZxUpkWH6TAeO+ 9Yr1PbD44th+fYc2KEKS0Z/ngBx98ChyC2Bi7kwTbMzrdxfvZ2KfWjviZSq/uf9BxcJ/ szVQ== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of tglx@linutronix.de designates 2a0a:51c0:0:12e:550::1 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-Gm-Message-State: APjAAAUwluTYh//XIayGSUeq8Q9cEgLeEIdukP4r5sSaitMffP4ZZ/47 sYKxOQXOpmYRV3om/Ie44ScZsMnu/cCum2rNR+YZIeyU+S7rwv9vygfr5j2HYd0xbnbfTL4JIw+ 05gdUUeUE+8PE4O7nmS0/i7/3uS82tBtJx57iEQYcdXr3Mhr9BsN58X12O4vBQRVk/Q== X-Received: by 2002:a19:ca4b:: with SMTP id h11mr13139999lfj.162.1562738342783; Tue, 09 Jul 2019 22:59:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZcyWZLpH8JlPMC8DnOMYnKopf3V4HNJEVekg5nmWp8A6j7XdGx7byUuCUFwF5EJipsumN X-Received: by 2002:a19:ca4b:: with SMTP id h11mr13139953lfj.162.1562738341986; Tue, 09 Jul 2019 22:59:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562738341; cv=none; d=google.com; s=arc-20160816; b=scNLGRpMzIAsnB57kdrj7OI2vRbmBpgNsl/ZVK0lCe882hsw2NmrPanTo+GpnxDgGF tMYfPvFCL89dCBgQZhvFNE4WOhpsDbW2DbFVeThiStQFhR7Q7rgqlW2yc/GSbU8lfLqj pQW7kvhaLfVtHi21UUk4rNuO+mzJ1L3d3tBFgLrbXpNE2sECFeA8lYrHQgh72TOTdhWH KCSKyk7tIHte8vbp55WnEkDBgkGvfSgyvr8OcsPpsBsFr7YjnvP89ao1Gjx72yIFTjng goH0ggXXiTyneA+L2Sn6f7xCNfAY+WNv+LINWxmZQewFZkXHrwkdLypKZ8DoilDw8jWV CLJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date; bh=PDwHUB/U1Dx9d92PPEJemltmsVvg53siDRKnpPtq0As=; b=CCMLlQkklRL+V7/em5uX0cwVkJAniDXun19C5eiAy/kePghgPCMu2Qfmv+oy3/x0jM PsTgcwmR/OpZw6zo6kZkZbZk6hXdOqXmJQ7od7wLUzo10AkcpZ4FI7DQhcPDKAhkdycO WR+UB/rbgOrwG8wpn9O/hiITvsQXvmsDLFmotgu1lC1FtYVmTlxEkZ9mrrUteLl42xW5 AFweg/sEARKrrs336qSxRizJdfdlTXgykxWjOJRrHX5REjD0oBv9m//gCqP4N1BR0V3i UiNx+g5teeeAkF13vetjqiiJ8mcG2qfFTPMGggFC8JqND5zVzjP+PiGaOvbEnX2IiVx3 x6Nw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of tglx@linutronix.de designates 2a0a:51c0:0:12e:550::1 as permitted sender) smtp.mailfrom=tglx@linutronix.de Received: from Galois.linutronix.de (Galois.linutronix.de. [2a0a:51c0:0:12e:550::1]) by mx.google.com with ESMTPS id q16si1077282wrn.437.2019.07.09.22.59.01 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 09 Jul 2019 22:59:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of tglx@linutronix.de designates 2a0a:51c0:0:12e:550::1 as permitted sender) client-ip=2a0a:51c0:0:12e:550::1; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of tglx@linutronix.de designates 2a0a:51c0:0:12e:550::1 as permitted sender) smtp.mailfrom=tglx@linutronix.de Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hl5cV-0004bB-Pv; Wed, 10 Jul 2019 07:58:23 +0200 Date: Wed, 10 Jul 2019 07:58:21 +0200 (CEST) From: Thomas Gleixner To: Hoan Tran OS cc: Catalin Marinas , Will Deacon , Andrew Morton , Michal Hocko , Vlastimil Babka , Oscar Salvador , Pavel Tatashin , Mike Rapoport , Alexander Duyck , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , 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" , Open Source Submission Subject: Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES In-Reply-To: <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> Message-ID: References: <1561501810-25163-1-git-send-email-Hoan@os.amperecomputing.com> <1561501810-25163-4-git-send-email-Hoan@os.amperecomputing.com> <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hoan, On Wed, 10 Jul 2019, Hoan Tran OS wrote: > On 6/25/19 3:45 PM, Thomas Gleixner wrote: > > On Tue, 25 Jun 2019, Hoan Tran OS wrote: > >> @@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA > >> ---help--- > >> Enable ACPI SRAT based node topology detection. > >> > >> -# Some NUMA nodes have memory ranges that span > >> -# other nodes. Even though a pfn is valid and > >> -# between a node's start and end pfns, it may not > >> -# reside on that node. See memmap_init_zone() > >> -# for details. > >> -config NODES_SPAN_OTHER_NODES > >> - def_bool y > >> - depends on X86_64_ACPI_NUMA > > > > the changelog does not mention that this lifts the dependency on > > X86_64_ACPI_NUMA and therefore enables that functionality for anything > > which has NUMA enabled including 32bit. > > > > I think this config is used for a NUMA layout which NUMA nodes addresses > are spanned to other nodes. I think 32bit NUMA also have the same issue > with that layout. Please correct me if I'm wrong. I'm not saying you're wrong, but it's your duty to provide the analysis why this is correct for everything which has NUMA enabled. > > The core mm change gives no helpful information either. You just copied the > > above comment text from some random Kconfig. > > Yes, as it's a correct comment and is used at multiple places. Well it maybe correct in terms of explaining what this is about, it still does not explain why this is needed by default on everything which has NUMA enabled. Thanks, tglx 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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 E42CEC73C6D for ; Wed, 10 Jul 2019 06:00:53 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 3E73320838 for ; Wed, 10 Jul 2019 06:00:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E73320838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45k7pV5J1czDqXd for ; Wed, 10 Jul 2019 16:00:50 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (mailfrom) smtp.mailfrom=linutronix.de (client-ip=2a0a:51c0:0:12e:550::1; helo=galois.linutronix.de; envelope-from=tglx@linutronix.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linutronix.de Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45k7mY21DWzDqXX for ; Wed, 10 Jul 2019 15:59:08 +1000 (AEST) Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hl5cV-0004bB-Pv; Wed, 10 Jul 2019 07:58:23 +0200 Date: Wed, 10 Jul 2019 07:58:21 +0200 (CEST) From: Thomas Gleixner To: Hoan Tran OS Subject: Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES In-Reply-To: <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> Message-ID: References: <1561501810-25163-1-git-send-email-Hoan@os.amperecomputing.com> <1561501810-25163-4-git-send-email-Hoan@os.amperecomputing.com> <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michal Hocko , Catalin Marinas , Heiko Carstens , "open list:MEMORY MANAGEMENT" , Paul Mackerras , "H . Peter Anvin" , "sparclinux@vger.kernel.org" , Alexander Duyck , "linux-s390@vger.kernel.org" , "x86@kernel.org" , Mike Rapoport , Christian Borntraeger , Ingo Molnar , Vlastimil Babka , Open Source Submission , Pavel Tatashin , Vasily Gorbik , Will Deacon , Borislav Petkov , "linux-arm-kernel@lists.infradead.org" , Oscar Salvador , "linux-kernel@vger.kernel.org" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , "David S . Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hoan, On Wed, 10 Jul 2019, Hoan Tran OS wrote: > On 6/25/19 3:45 PM, Thomas Gleixner wrote: > > On Tue, 25 Jun 2019, Hoan Tran OS wrote: > >> @@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA > >> ---help--- > >> Enable ACPI SRAT based node topology detection. > >> > >> -# Some NUMA nodes have memory ranges that span > >> -# other nodes. Even though a pfn is valid and > >> -# between a node's start and end pfns, it may not > >> -# reside on that node. See memmap_init_zone() > >> -# for details. > >> -config NODES_SPAN_OTHER_NODES > >> - def_bool y > >> - depends on X86_64_ACPI_NUMA > > > > the changelog does not mention that this lifts the dependency on > > X86_64_ACPI_NUMA and therefore enables that functionality for anything > > which has NUMA enabled including 32bit. > > > > I think this config is used for a NUMA layout which NUMA nodes addresses > are spanned to other nodes. I think 32bit NUMA also have the same issue > with that layout. Please correct me if I'm wrong. I'm not saying you're wrong, but it's your duty to provide the analysis why this is correct for everything which has NUMA enabled. > > The core mm change gives no helpful information either. You just copied the > > above comment text from some random Kconfig. > > Yes, as it's a correct comment and is used at multiple places. Well it maybe correct in terms of explaining what this is about, it still does not explain why this is needed by default on everything which has NUMA enabled. Thanks, tglx 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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 F394CC73C73 for ; Wed, 10 Jul 2019 05:59:12 +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 C65BA20838 for ; Wed, 10 Jul 2019 05:59:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RmTMejva" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C65BA20838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de 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:MIME-Version:References:Message-ID: In-Reply-To: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=d8ivFQUDlVNKcDCGtJ6Y7B2kK/PBqOPvx+eDhI6+hsE=; b=RmTMejvapoKPW6 r2KAthQ5Ck4Rp5Y8YKJ+14zZQ/x/r1L+0Rz0YWtfCr2peLpsBnNEXFHYu6UemSk6Gu1gSjpDCxyuJ 8HYszm009CavqW9ZETnKg+XIz2IpBvp6eMLrSCbZ1HVOmyYjCvevA5UwJh1DJcCsoGfJOxYt4h+Sp IVOGz3EJAqK/jLlMCtzcOAnngPMp5O1Zdj85lwjKhxPYfe+jig+xJaZATYJtzvSM0rvtwsh9G1Myb pdKmwPi9WKaqONAtM3o+J8ScW1qU9m6IvURB1zP5UnfXxsJp1r3QG0ouCAj0HspS2mjHSpglK+hB/ oe2I9JZuPzzTrXculc6w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hl5dH-0002DV-AS; Wed, 10 Jul 2019 05:59:11 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hl5dD-0002CQ-Rx for linux-arm-kernel@lists.infradead.org; Wed, 10 Jul 2019 05:59:09 +0000 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hl5cV-0004bB-Pv; Wed, 10 Jul 2019 07:58:23 +0200 Date: Wed, 10 Jul 2019 07:58:21 +0200 (CEST) From: Thomas Gleixner To: Hoan Tran OS Subject: Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES In-Reply-To: <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> Message-ID: References: <1561501810-25163-1-git-send-email-Hoan@os.amperecomputing.com> <1561501810-25163-4-git-send-email-Hoan@os.amperecomputing.com> <1c5bc3a8-0c6f-dce3-95a2-8aec765408a2@os.amperecomputing.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190709_225908_047252_80815282 X-CRM114-Status: GOOD ( 19.15 ) 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: Michal Hocko , 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" , Mike Rapoport , Christian Borntraeger , Ingo Molnar , Vlastimil Babka , Benjamin Herrenschmidt , Open Source Submission , Pavel Tatashin , Vasily Gorbik , Will Deacon , Borislav Petkov , "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 Hoan, On Wed, 10 Jul 2019, Hoan Tran OS wrote: > On 6/25/19 3:45 PM, Thomas Gleixner wrote: > > On Tue, 25 Jun 2019, Hoan Tran OS wrote: > >> @@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA > >> ---help--- > >> Enable ACPI SRAT based node topology detection. > >> > >> -# Some NUMA nodes have memory ranges that span > >> -# other nodes. Even though a pfn is valid and > >> -# between a node's start and end pfns, it may not > >> -# reside on that node. See memmap_init_zone() > >> -# for details. > >> -config NODES_SPAN_OTHER_NODES > >> - def_bool y > >> - depends on X86_64_ACPI_NUMA > > > > the changelog does not mention that this lifts the dependency on > > X86_64_ACPI_NUMA and therefore enables that functionality for anything > > which has NUMA enabled including 32bit. > > > > I think this config is used for a NUMA layout which NUMA nodes addresses > are spanned to other nodes. I think 32bit NUMA also have the same issue > with that layout. Please correct me if I'm wrong. I'm not saying you're wrong, but it's your duty to provide the analysis why this is correct for everything which has NUMA enabled. > > The core mm change gives no helpful information either. You just copied the > > above comment text from some random Kconfig. > > Yes, as it's a correct comment and is used at multiple places. Well it maybe correct in terms of explaining what this is about, it still does not explain why this is needed by default on everything which has NUMA enabled. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel