# Re: \[PATCH v3 1/2\] mm: introduce process\_mrelease system call

- List: linux-api
- 2 messages, 2 authors
- Page: https://ratatoskr.run/linux-api/2021/07/1455648/t

## Re: \[PATCH v3 1/2\] mm: introduce process\_mrelease system call

- From: David Hildenbrand \<hidden\>
- Date: 2021-07-23 08:15:46 
- Message: https://ratatoskr.run/linux-api/2021/07/1455648.md

```text
On 23.07.21 10:11, Suren Baghdasaryan wrote:
>
>
> 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 ...


-- 
Thanks,

David / dhildenb

```

## Re: \[PATCH v3 1/2\] mm: introduce process\_mrelease system call

- From: Suren Baghdasaryan \<surenb@google.com\>
- Date: 2021-07-23 08:19:11 
- Message: https://ratatoskr.run/linux-api/2021/07/1455660.md

```text
On Fri, Jul 23, 2021 at 1:15 AM David Hildenbrand [ref] wrote:
>
> On 23.07.21 10:11, Suren Baghdasaryan wrote:
> >
> >
> > 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.
>
```