Re: [PATCH v3 1/2] mm: introduce process_mrelease system call

On Fri, Jul 23, 2021 at 1:15 AM David Hildenbrand [off-list ref] wrote:

On 23.07.21 10:11, Suren Baghdasaryan wrote:

quoted

On Thu, Jul 22, 2021, 11:20 PM Michal Hocko <mhocko@suse.com
<mailto:mhocko@suse.com>> wrote:

    On Thu 22-07-21 21:47:56, Suren Baghdasaryan wrote:
     > On Thu, Jul 22, 2021, 7:04 PM Shakeel Butt <shakeelb@google.com
    <mailto:shakeelb@google.com>> wrote:
     >
     > > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan
    <surenb@google.com <mailto:surenb@google.com>>
     > > wrote:
     > > >
     > > [...]
     > > > +
     > > > +       mmap_read_lock(mm);
     > >
     > > How about mmap_read_trylock(mm) and return -EAGAIN on failure?
     > >
     >
     > That sounds like a good idea. Thanks! I'll add that in the next
    respin.

    Why is that a good idea? Can you do anything meaningful about the
    failure other than immediately retry the syscall and hope for the best?


I was thinking if this syscall implements "best effort without blocking"
approach then for a more strict usage user can simply retry. However
retrying means issuing another syscall, so additional overhead...
I guess such "best effort" approach would be unusual for a syscall, so
maybe we can keep it as it is now and if such "do not block" mode is
needed we can use flags to implement it later?

The process is dying, so I am not sure what we are trying to optimize
here in respect to locking ...

Trying not to block the caller, which is likely a system health
monitoring process. However, if not blocking is important, it can
issue this syscall from a separate thread... Let's scratch that "do
not block" mode and keep it simple as it is now.

--
Thanks,

David / dhildenb

--
To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.