linux-kernel - Re: [PATCH v2 0/3] mm: use memmap_on

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1c3f737e-f5c6-b974-3b36-c4a3ada14422@redhat.com>
Date:   Tue, 25 Jul 2023 17:54:17 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Vishal Verma <vishal.l.verma@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oscar Salvador <osalvador@...e.de>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Jiang <dave.jiang@...el.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        nvdimm@...ts.linux.dev, linux-cxl@...r.kernel.org,
        Huang Ying <ying.huang@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Jeff Moyer <jmoyer@...hat.com>
Subject: Re: [PATCH v2 0/3] mm: use memmap_on_memory semantics for dax/kmem

On 20.07.23 09:14, Vishal Verma wrote:
> The dax/kmem driver can potentially hot-add large amounts of memory
> originating from CXL memory expanders, or NVDIMMs, or other 'device
> memories'. There is a chance there isn't enough regular system memory
> available to fit the memmap for this new memory. It's therefore
> desirable, if all other conditions are met, for the kmem managed memory
> to place its memmap on the newly added memory itself.
> 
> The main hurdle for accomplishing this for kmem is that memmap_on_memory
> can only be done if the memory being added is equal to the size of one
> memblock. To overcome this,allow the hotplug code to split an add_memory()
> request into memblock-sized chunks, and try_remove_memory() to also
> expect and handle such a scenario.
> 
> Patch 1 exports mhp_supports_memmap_on_memory() so it can be used by the
> kmem driver.
> 
> Patch 2 teaches the memory_hotplug code to allow for splitting
> add_memory() and remove_memory() requests over memblock sized chunks.
> 
> Patch 3 adds a sysfs control for the kmem driver that would
> allow an opt-out of using memmap_on_memory for the memory being added.
> 

It might be reasonable to rebase this on Aneesh's work. For example, 
patch #1 might not be required anymore.

-- 
Cheers,

David / dhildenb