Re: [RFC PATCH v3 00/10] Add support for shared PTEs across processes

[Anthony Yznaga]

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, ...