[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXlK74ZlUf76nBE_@gourry-fedora-PF4VCD3F>
Date: Tue, 27 Jan 2026 18:31:59 -0500
From: Gregory Price <gourry@...rry.net>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Jonathan Cameron <jonathan.cameron@...wei.com>, linux-mm@...ck.org,
linux-cxl@...r.kernel.org, nvdimm@...ts.linux.dev,
linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
kernel-team@...a.com, dan.j.williams@...el.com,
vishal.l.verma@...el.com, dave.jiang@...el.com, mst@...hat.com,
jasowang@...hat.com, xuanzhuo@...ux.alibaba.com,
eperezma@...hat.com, osalvador@...e.de, akpm@...ux-foundation.org
Subject: Re: [PATCH 3/8] mm/memory_hotplug: add APIs for explicit online type
control
On Wed, Jan 28, 2026 at 12:06:01AM +0100, David Hildenbrand (Red Hat) wrote:
> I'd go for
>
> EXPORT_SYMBOL_FOR_MODULES(__add_memory_driver_managed, "dax")
>
> (or would it be the kmem module?)
>
it would be kmem.
I'll let the accelerator folks argue for loosening the restriction for
OOT modules, for me I think this is sufficient.
In the long term, for the private-node set, i think this might also be
ok, as the intent is to only allow "enlightened users" access to private
nodes anyway - zones are less important since the driver still has
a say in how memory gets moved there.
(e.g. compressed-memory is a demotion-only target, which implies only
only movable allocations can occur there... so zones are mostly
pointless and the whole policy setup can be ignored and the original
interface can just be used)
~Gregory
Powered by blists - more mailing lists