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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 23.07.21 10:11, Suren Baghdasaryan wrote:


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

    On Thu 22-07-21 21:47:56, Suren Baghdasaryan wrote:
     > On Thu, Jul 22, 2021, 7:04 PM Shakeel Butt <shakeelb@xxxxxxxxxx
    <mailto:shakeelb@xxxxxxxxxx>> wrote:
     >
     > > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan
    <surenb@xxxxxxxxxx <mailto:surenb@xxxxxxxxxx>>
     > > 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




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux