[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200311112700.GD3216816@arrakis.emea.arm.com>
Date: Wed, 11 Mar 2020 11:27:00 +0000
From: Catalin Marinas <catalin.marinas@....com>
To: Hoan Tran <hoan@...amperecomputing.com>
Cc: Will Deacon <will@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
patches@...amperecomputing.com
Subject: Re: [PATCH] arm64: Kconfig: Enable NODES_SPAN_OTHER_NODES config for
NUMA
On Thu, Feb 06, 2020 at 12:01:19PM -0800, Hoan Tran wrote:
> Hi Will,
>
> On 2/6/20 2:23 AM, Will Deacon wrote:
> > On Mon, Feb 03, 2020 at 11:55:14AM -0800, Hoan Tran wrote:
> > > 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.
> > >
> > > This patch enables NODES_SPAN_OTHER_NODES config for NUMA to support
> > > this type of NUMA layout.
> > >
> > > Signed-off-by: Hoan Tran <Hoan@...amperecomputing.com>
> > > ---
> > > arch/arm64/Kconfig | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index e688dfa..939d28f 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -959,6 +959,13 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> > > config HOLES_IN_ZONE
> > > def_bool y
> > > +# 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.
> > > +config NODES_SPAN_OTHER_NODES
> > > + def_bool y
> > > + depends on ACPI_NUMA
> > > +
> >
> > I thought we agreed to do this in the core code?
> >
> > https://lore.kernel.org/lkml/1562887528-5896-1-git-send-email-Hoan@os.amperecomputing.com
>
> Yes, but it looks like Thomas didn't agree to apply this patch into
> x86.
>
> https://lore.kernel.org/lkml/alpine.DEB.2.21.1907152042110.1767@nanos.tec.linutronix.de/
Was it a clear statement that such change will not make it to x86 or a
request for improving the patch or the description? I'd suggest you
update the x86 patch comment to include the rationale as per your reply
to Thomas and post a new version of the generic series. If Thomas (or
the mm folk) reject it again, we'll revisit the arm64-specific thread.
--
Catalin
Powered by blists - more mailing lists