From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Gregory Price <gourry@gourry.net>, sashiko-reviews@lists.linux.dev
Cc: linux-mm@kvack.org
Subject: Re: [PATCH v4 6/9] dax: plumb hotplug online_type through dax
Date: Tue, 9 Jun 2026 12:21:34 +0200 [thread overview]
Message-ID: <878faef6-bbd3-43ec-af82-6da675a5f8fe@kernel.org> (raw)
In-Reply-To: <aiNFezMarbvIZNa0@gourry-fedora-PF4VCD3F>
On 6/5/26 23:54, Gregory Price wrote:
> On Fri, Jun 05, 2026 at 09:31:43PM +0000, sashiko-bot@kernel.org wrote:
>>
>>> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
>>> index 592171ec10f49..41ccb618a1464 100644
>>> --- a/drivers/dax/kmem.c
>>> +++ b/drivers/dax/kmem.c
>>> @@ -172,8 +172,9 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
>>> * Ensure that future kexec'd kernels will not treat
>>> * this as RAM automatically.
>>> */
>>> - rc = add_memory_driver_managed(data->mgid, range.start,
>>> - range_len(&range), kmem_name, mhp_flags);
>>> + rc = __add_memory_driver_managed(data->mgid, range.start,
>>> + range_len(&range), kmem_name, mhp_flags,
>>> + dev_dax->online_type);
>>
>> [Severity: High]
>> Does capturing the auto-online policy at device creation time break dynamic
>> sysfs policy changes?
>>
>
> @David - we talked about this ~6+ mo ago at this point, i originally
> proposed something like MMOP_SYSTEM_DEFAULT
>
> https://lore.kernel.org/linux-mm/20260114085201.3222597-3-gourry@gourry.net/
>
> https://lore.kernel.org/linux-mm/c4ed9675-269c-4764-86d5-87f4f83fc74d@kernel.org/
>
> '''
> I don't like having fake options as part of this interface.
>
> Why can't we let selected users use mhp_get_default_online_type()
> instead? Like add_memory_resource(). We can export that function.
> '''
>
> I guess the argument here is that the value can't be cached?
>
> But we can't really enforce that.
>
> This is a behavioral change we have to agree on (either we change it or
> carry something like MMOP_SYSTEM_DEFAULT for this).
I don't think we'd need a generic MMOP_* for that purpose (the core cannot
really do a lot with that AFAIKS, and the scenario "unspecified" doesn't really
occur in memory hotplug core).
I guess you could have some indication whether the user already configured it
manually (bool online_type_specified), and handle that in the handful of places.
if (dev_dax->online_type_specified)
online_type = dev_dax->online_type;
else
online_type = mhp_get_default_online_type();
Of course, you could also just call the old interface when adding without a
preference.
A negative online_type could also be used as "unspecified" in your code (MMOP_
starts at 0).
But the question really is which semantics we would want? is that exposed to
user-space somehow, such that the user could query it ("default")? or how does
this get set, and how does it later get used while it could have changed
system-wide?
--
Cheers,
David
next prev parent reply other threads:[~2026-06-09 10:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 21:19 [PATCH v4 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price
2026-06-05 21:19 ` [PATCH v4 1/9] mm/memory: add memory_block_aligned_range() helper Gregory Price
2026-06-09 9:50 ` David Hildenbrand (Arm)
2026-06-05 21:19 ` [PATCH v4 2/9] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-06-05 21:19 ` [PATCH v4 3/9] mm/memory_hotplug: export mhp_get_default_online_type Gregory Price
2026-06-05 21:29 ` sashiko-bot
2026-06-05 21:43 ` Gregory Price
2026-06-09 9:52 ` David Hildenbrand (Arm)
2026-06-09 15:11 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 4/9] mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg Gregory Price
2026-06-09 9:55 ` David Hildenbrand (Arm)
2026-06-09 15:12 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 5/9] mm/memory_hotplug: add multi-range hotunplug Gregory Price
2026-06-05 21:30 ` sashiko-bot
2026-06-09 10:06 ` David Hildenbrand (Arm)
2026-06-09 15:15 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 6/9] dax: plumb hotplug online_type through dax Gregory Price
2026-06-05 21:31 ` sashiko-bot
2026-06-05 21:54 ` Gregory Price
2026-06-09 10:21 ` David Hildenbrand (Arm) [this message]
2026-06-09 15:33 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 7/9] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-06-05 21:36 ` sashiko-bot
2026-06-05 22:03 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 8/9] dax/kmem: add sysfs interface for atomic hotplug Gregory Price
2026-06-05 21:37 ` sashiko-bot
2026-06-09 10:26 ` David Hildenbrand (Arm)
2026-06-09 15:35 ` Gregory Price
2026-06-09 18:11 ` David Hildenbrand (Arm)
2026-06-09 18:19 ` Gregory Price
2026-06-09 18:22 ` David Hildenbrand (Arm)
2026-06-09 18:33 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 9/9] selftests/dax: add dax/kmem hotplug sysfs regression test Gregory Price
2026-06-05 21:34 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878faef6-bbd3-43ec-af82-6da675a5f8fe@kernel.org \
--to=david@kernel.org \
--cc=gourry@gourry.net \
--cc=linux-mm@kvack.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.