On Tue, Sep 10, 2019 at 1:31 AM Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> wrote: > > On 9/10/19 1:40 PM, Dan Williams wrote: > > On Mon, Sep 9, 2019 at 11:29 PM Aneesh Kumar K.V > > <aneesh.ku...@linux.ibm.com> wrote: > >> > >> With PFN_MODE_PMEM namespace, the memmap area is allocated from the device > >> area. Some architectures map the memmap area with large page size. On > >> architectures like ppc64, 16MB page for memap mapping can map 262144 pfns. > >> This maps a namespace size of 16G. > >> > >> When populating memmap region with 16MB page from the device area, > >> make sure the allocated space is not used to map resources outside this > >> namespace. Such usage of device area will prevent a namespace destroy. > >> > >> Add resource end pnf in altmap and use that to check if the memmap area > >> allocation can map pfn outside the namespace. On ppc64 in such case we > >> fallback > >> to allocation from memory. > > > > Shouldn't this instead be comprehended by nd_pfn_init() to increase > > the reservation size so that it fits in the alignment? It may not > > always be possible to fall back to allocation from memory for > > extremely large pmem devices. I.e. at 64GB of memmap per 1TB of pmem > > there may not be enough DRAM to store the memmap. > > > > We do switch between DRAM and device for memmap allocation. ppc64 > vmemmap_populate does > > if (altmap && !altmap_cross_boundary(altmap, start, page_size)) { > p = altmap_alloc_block_buf(page_size, altmap); > if (!p) > pr_debug("altmap block allocation failed, falling back to > system memory"); > } > if (!p) > p = vmemmap_alloc_block_buf(page_size, node); > > > With that we should be using DRAM for the first and the last mapping, > rest of the memmap should be backed by device.
Ah, ok, makes sense.