RE: [PATCH v2 08/22] memblock: Introduce a generic phys_addr_to_target_node()

[Justin He]

Hi Dan

> -----Original Message-----
> From: Dan Williams <dan.j.williams@xxxxxxxxx>
> Sent: Monday, July 13, 2020 11:48 PM
> To: Mike Rapoport <rppt@xxxxxxxxxxxxx>
> Cc: linux-nvdimm <linux-nvdimm@xxxxxxxxxxxx>; Justin He
> <Justin.He@xxxxxxx>; Will Deacon <will@xxxxxxxxxx>; David Hildenbrand
> <david@xxxxxxxxxx>; Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; Peter
> Zijlstra <peterz@xxxxxxxxxxxxx>; Vishal L Verma <vishal.l.verma@xxxxxxxxx>;
> Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>; Ard Biesheuvel
> <ard.biesheuvel@xxxxxxxxxx>; Linux MM <linux-mm@xxxxxxxxx>; Linux Kernel
> Mailing List <linux-kernel@xxxxxxxxxxxxxxx>; Linux ACPI <linux-
> acpi@xxxxxxxxxxxxxxx>; Christoph Hellwig <hch@xxxxxx>; Joao Martins
> <joao.m.martins@xxxxxxxxxx>
> Subject: Re: [PATCH v2 08/22] memblock: Introduce a generic
> phys_addr_to_target_node()
>
> On Mon, Jul 13, 2020 at 12:04 AM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote:
> >
> > Hi Dan,
> >
> > On Sun, Jul 12, 2020 at 09:26:48AM -0700, Dan Williams wrote:
> > > Similar to how generic memory_add_physaddr_to_nid() interrogates
> > > memblock data for numa information, introduce
> > > get_reserved_pfn_range_from_nid() to enable the same operation for
> > > reserved memory ranges. Example memory ranges that are reserved, but
> > > still have associated numa-info are persistent memory or Soft Reserved
> > > (EFI_MEMORY_SP) memory.
> >
> > Here again, I would prefer to add a weak default for
> > phys_to_target_node() because the "generic" implementation is not really
> > generic.
> >
> > The fallback to reserved ranges is x86 specfic because on x86 most of
> the
> > reserved areas is not in memblock.memory. AFAIK, no other architecture
> > does this.
>
> True, I was pre-fetching ARM using the new EFI "Special Purpose"
> memory attribute. However, until that becomes something that platforms
> deploy in practice I'm ok with not solving that problem for now.
>
> > And x86 anyway has implementation of phys_to_target_node().
>
> Sure, let's go with the default stub for non-x86.
>
> Justin, do you think it would make sense to fold your dax_kmem
> enabling for arm64 series into my enabling of dax_hmem for all
> memory-hotplug archs?

It is ok with me, thanks for the folding ð

--
Cheers,
Justin (Jia He)



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.