linux-kernel - Re: [PATCH v3 1/5] mm,memory_hotplug: Allocate memmap from the added memory range

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <830F715B-82B4-4A13-861F-B3A89327F722@nvidia.com>
Date:   Sun, 07 Mar 2021 22:16:36 -0500
From:   "Zi Yan" <ziy@...dia.com>
To:     "Oscar Salvador" <osalvador@...e.de>
Cc:     "Andrew Morton" <akpm@...ux-foundation.org>,
        "David Hildenbrand" <david@...hat.com>,
        "Michal Hocko" <mhocko@...nel.org>,
        "Anshuman Khandual" <anshuman.khandual@....com>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        "Pavel Tatashin" <pasha.tatashin@...een.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        "Mike Kravetz" <mike.kravetz@...cle.com>
Subject: Re: [PATCH v3 1/5] mm,memory_hotplug: Allocate memmap from the added
 memory range

On 4 Mar 2021, at 4:59, Oscar Salvador wrote:

> Physical memory hotadd has to allocate a memmap (struct page array) for
> the newly added memory section. Currently, alloc_pages_node() is used
> for those allocations.
>
> This has some disadvantages:
>  a) an existing memory is consumed for that purpose
>     (eg: ~2MB per 128MB memory section on x86_64)
>  b) if the whole node is movable then we have off-node struct pages
>     which has performance drawbacks.
>  c) It might be there are no PMD_ALIGNED chunks so memmap array gets
>     populated with base pages.
>
> This can be improved when CONFIG_SPARSEMEM_VMEMMAP is enabled.
>
> Vmemap page tables can map arbitrary memory.
> That means that we can simply use the beginning of each memory section and
> map struct pages there.
> struct pages which back the allocated space then just need to be treated
> carefully.
>
> Implementation wise we will reuse vmem_altmap infrastructure to override
> the default allocator used by __populate_section_memmap.
> Part of the implementation also relies on memory_block structure gaining
> a new field which specifies the number of vmemmap_pages at the beginning.
> This comes in handy as in {online,offline}_pages, all the isolation and
> migration is being done on (buddy_start_pfn, end_pfn] range,
> being buddy_start_pfn = start_pfn + nr_vmemmap_pages.
>
> In this way, we have:
>
> [start_pfn, buddy_start_pfn - 1] = Initialized and PageReserved
> [buddy_start_pfn, end_pfn - 1]       = Initialized and sent to buddy

+Mike for hugetlb discussion.

Just thinking about how it might impact gigantic page allocation like hugetlb.
When MHP_MEMMAP_ON_MEMORY is on, memmap pages are placed at the beginning
of each hot added memory block, so available PFNs from two consecutive
hot added memory blocks are not all contiguous, separated by memmap pages.
If the memory block size is <= 1GB, there is no way of reserving gigantic
pages for hugetlb during runtime using alloc_contig_pages from any hot
added memory. Am I getting this right?

I see this implication is documented at the high level in patch 3. Just
wonder if we want to be more specific. Or hugetlb is rarely used along
with hot-add memory.

Thanks.

—
Best Regards,
Yan Zi

Download attachment "signature.asc" of type "application/pgp-signature" (855 bytes)