On 10/7/24 12:41 PM, David Hildenbrand wrote:
On 07.10.24 21:23, Anthony Yznaga wrote:
On 10/7/24 2:01 AM, Kirill A. Shutemov wrote:
On Tue, Sep 03, 2024 at 04:22:31PM -0700, Anthony Yznaga wrote:
This patch series implements a mechanism that allows userspace
processes to opt into sharing PTEs. It adds a new in-memory
filesystem - msharefs. A file created on msharefs represents a
shared region where all processes mapping that region will map
objects within it with shared PTEs. When the file is created,
a new host mm struct is created to hold the shared page tables
and vmas for objects later mapped into the shared region. This
host mm struct is associated with the file and not with a task.
Taskless mm_struct can be problematic. Like, we don't have access to
it's
counters because it is not represented in /proc. For instance,
there's no
way to check its smaps.
Definitely needs exposure in /proc. One of the things I'm looking into
is the feasibility of showing the mappings in maps/smaps/etc..
Also, I *think* it is immune to oom-killer because oom-killer looks
for a
victim task, not mm.
I hope it is not an intended feature :P
oom-killer would have to kill all sharers of an mshare region before the
mshare region itself could be freed, but I'm not sure that oom-killer
would be the one to free the region. An mshare region is essentially a
shared memory object not unlike a tmpfs or hugetlb file. I think some
higher level intelligence would have to be involved to release it if
appropriate when under oom conditions.
I thought we discussed that at LSF/MM last year and the conclusion was
that a process is needed (OOM kill, cgroup handling, ...), and it must
remain running. Once it stops running, we can force-unmap all pages etc.
Did you look at the summary/(recording if available) of that, or am I
remembering things wrongly or was there actually such a discussion?
You're likely right. I'll review the discussion.
Anthony
I know, it's problematic that this feature switched owners, ...
