From: Michal Hocko <mhocko@suse.com>
To: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hannes Reinecke <hare@kernel.org>
Subject: Re: [RFC] Disable auto_movable_ratio for selfhosted memmap
Date: Mon, 28 Jul 2025 14:17:24 +0200 [thread overview]
Message-ID: <aIdqVNCY-XMNICng@tiehlicka> (raw)
In-Reply-To: <79919ace-9cd2-4600-9615-6dc26ba19e19@redhat.com>
On Mon 28-07-25 11:10:44, David Hildenbrand wrote:
> On 28.07.25 11:04, Michal Hocko wrote:
> > On Mon 28-07-25 10:53:08, David Hildenbrand wrote:
[...]
> > > daxctl wants to online memory itself. We want to keep that memory offline
> > > from a kernel perspective and let daxctl handle it in this case.
> > >
> > > We have that problem in RHEL where we currently require user space to
> > > disable udev rules so daxctl "can win".
> >
> > ... this is the result. Those shouldn't really race. If udev is suppose
> > to see the device then only in its entirity so regular memory block
> > based onlining rules shouldn't even see that memory. Or am I completely
> > missing the picture?
>
> We can't break user space, which relies on individual memory blocks.
We do have userspace which onlines specific memory blocks and we cannot
break that. But do we have any userspace that wants to online CXL like
memory (or in general dax like memory) that would need to operate on
those memory blocks with that kind of granularity?
In other words what would break if we didn't expose CXL memory through
memory blocks in sysfs?
> So udev or $whatever will right now see individual memory blocks. We could
> export the group id to user space if that is of any help, but at least for
> daxctl purposes, it will be sufficient to identify "oh, this was added by
> dax/kmem" (which we can obtain from /proc/iomem) and say "okay, I'll let
> user-space deal with it."
>
> Having the whole thing exposed as a unit is not really solving any problems
> unless I am missing something important.
If we need to handle that thing as whole we should have an interface
that allows for that. Per block breakdown doesn't really help anything.
It just makes the whole problem much more complex.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2025-07-28 12:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 8:15 Oscar Salvador
2025-07-28 8:44 ` David Hildenbrand
2025-07-28 9:28 ` Hannes Reinecke
2025-07-28 9:42 ` David Hildenbrand
2025-07-28 8:48 ` Michal Hocko
2025-07-28 8:53 ` David Hildenbrand
2025-07-28 9:04 ` Michal Hocko
2025-07-28 9:10 ` David Hildenbrand
2025-07-28 9:37 ` Hannes Reinecke
2025-07-28 13:06 ` Michal Hocko
2025-07-28 13:08 ` David Hildenbrand
2025-07-29 7:24 ` Hannes Reinecke
2025-07-29 9:19 ` Michal Hocko
2025-07-29 9:29 ` David Hildenbrand
2025-07-29 9:33 ` Hannes Reinecke
2025-07-29 11:58 ` Michal Hocko
2025-07-29 13:52 ` Hannes Reinecke
2025-07-28 15:15 ` David Hildenbrand
2025-07-28 12:17 ` Michal Hocko [this message]
2025-07-28 12:27 ` David Hildenbrand
2025-07-28 12:27 ` David Hildenbrand
2025-07-28 13:00 ` Michal Hocko
2025-07-28 13:03 ` David Hildenbrand
2025-07-28 12:54 ` Michal Hocko
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=aIdqVNCY-XMNICng@tiehlicka \
--to=mhocko@suse.com \
--cc=david@redhat.com \
--cc=hare@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox