On Mon, 6 Jul 2020 12:47:51 +0000 Justin He <justin...@arm.com> wrote:
> Hi Jonathan, thanks for the comments. > > > -----Original Message----- > > From: Jonathan Cameron <jonathan.came...@huawei.com> > > Sent: Monday, July 6, 2020 6:46 PM > > To: Justin He <justin...@arm.com> > > Cc: Catalin Marinas <catalin.mari...@arm.com>; Will Deacon > > <w...@kernel.org>; Andrew Morton <a...@linux-foundation.org>; Mike > > Rapoport <r...@linux.ibm.com>; Baoquan He <b...@redhat.com>; Chuhong Yuan > > <hsleste...@gmail.com>; linux-arm-ker...@lists.infradead.org; linux- > > ker...@vger.kernel.org; linux...@kvack.org; Kaly Xin <kaly....@arm.com> > > Subject: Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa node > > is fake > > > > On Mon, 6 Jul 2020 11:29:21 +0100 > > Jonathan Cameron <jonathan.came...@huawei.com> wrote: > > > > > On Mon, 6 Jul 2020 09:19:45 +0800 > > > Jia He <justin...@arm.com> wrote: > > > > > > Hi, > > > > > > > Previously, numa_off is set to true unconditionally in > > dummy_numa_init(), > > > > even if there is a fake numa node. > > > > > > > > But acpi will translate node id to NUMA_NO_NODE(-1) in > > acpi_map_pxm_to_node() > > > > because it regards numa_off as turning off the numa node. > > > > > > That is correct. It is operating exactly as it should, if SRAT hasn't > > been parsed > > > and you are on ACPI platform there are no nodes. They cannot be created > > at > > > some later date. The dummy code doesn't change this. It just does > > enough to carry > > > on operating with no specified nodes. > > > > > > > > > > > Without this patch, pmem can't be probed as a RAM device on arm64 if > > SRAT table > > > > isn't present. > > > > > > > > $ndctl create-namespace -fe namespace0.0 --mode=devdax --map=dev -s 1g > > -a 64K > > > > kmem dax0.0: rejecting DAX region [mem 0x240400000-0x2bfffffff] with > > invalid node: -1 > > > > kmem: probe of dax0.0 failed with error -22 > > > > > > > > This fixes it by setting numa_off to false. > > > > > > Without the SRAT protection patch [1] you may well run into problems > > Sorry, doesn't quite understand here. Do you mean your [1] can resolve this > issue? But acpi_map_pxm_to_node() has returned with NUMA_NO_NODE after > following check: > if (pxm < 0 || pxm >= MAX_PXM_DOMAINS || numa_off) > return NUMA_NO_NODE; The point of that patch is it will make it safe to remove the numa_off because any later accidental reference to a non existent node (i.e. one not defined in SRAT) will not blow up. It doesn't fix your original problem. What it does do, is fix the new problem case you introduce by removing numa_off below. It ensures you still return NUMA_NO_NODE in cases which should do so (i.e. all of them if you have no SRAT and are using ACPI). Of course, you could just not remove the numa_off = true bit then you won't hit that condition anyway. There are plenty of other reasons for the SRAT patch though, it just happens to close a problem you were introducing here as well. For reference we had an AMD platform that had no SRAT, but provided _PXM for a few nodes in its DSDT. That result in non booting systems. It only affected x86 because ARM64 had that numa_off = true being set. If we change the arm64 case without the patch to ensure the underlying problem is fixed, you are very likely to hit the equivalent problem. There may well be platforms out there relying on that quirk of what the code currently does. > Seems even with your [1] patch, it is not helpful? Thanks for clarification > if my understanding is wrong. > [1] https://patchwork.kernel.org/patch/11632063/ > > > > because someone somewhere will have _PXM in a DSDT but will > > > have a non existent SRAT. We had this happen on an AMD platform when > > we > > > tried to introduce working _PXM support for PCI. [2] > > > > > > So whilst this seems superficially safe, I'd definitely be crossing your > > fingers. > > > Note, at that time I proposed putting the numa_off = false into the x86 > > code > > > path precisely to cut out that possibility (was rejected at the time, at > > least > > > partly because the clarifications to the ACPI spec were not pubilc.) > > > > > > The patch in [1] should sort things out however by ensuring we only > > create > > > new domains where we should actually be doing so. However, in your case > > > it will return NUMA_NO_NODE anyway so this isn't the right way to fix > > things. > > Okay, let me try to summarize, there might be 3 possible fixing ways: > 1. this patch, seems it is not satisfied by you and David 😉 > 2. my previous proposal [2], similar as what David suggested That looks like the correct approach to me as well. > 3. remove numa_off check in acpi_map_pxm_to_node() No way to that one. The only right return value from acpi_map_pxm_to_node when no node is provided (always the case if you have no SRAT) is NUMA_NO_NODE. Do not paper over that - fix the caller to handle a perfectly valid return value. Jonathan > e.g. > ... > if (pxm < 0 || pxm >= MAX_PXM_DOMAINS /*|| numa_off*/) > return NUMA_NO_NODE; > > [2] https://lkml.org/lkml/2019/8/16/367 > > > -- > Cheers, > Justin (Jia He) > >
