lkml.org 
[lkml]   [2020]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 1/2] mm/madvise: allow process_madvise operations on entire memory range
    On Tue, Dec 22, 2020 at 11:57 PM Christoph Hellwig <hch@lst.de> wrote:
    >
    > On Tue, Dec 22, 2020 at 09:48:43AM -0800, Suren Baghdasaryan wrote:
    > > Thanks for the feedback! The use case is userspace memory reaping
    > > similar to oom-reaper. Detailed justification is here:
    > > https://lore.kernel.org/linux-mm/20201124053943.1684874-1-surenb@google.com
    >
    > Given that this new variant of process_madvise
    >
    > a) does not work on an address range

    True, however I can see other madvise flavors that could be used on
    the entire process. For example process_madvise(MADV_PAGEOUT) could be
    used to "shrink" an entire inactive background process.

    > b) is destructive

    I agree that memory reaping might be the only case when a destructive
    process_madvise() makes sense. Unless the target process is dying, a
    destructive process_madvise() would need coordination with the target
    process, and if it's coordinated then the target might as well call
    normal madvise() itself.

    > c) doesn't share much code at all with the rest of process_madvise

    It actually does reuse a considerable part of the code, but the same
    code can be refactored and reused either way.

    >
    > Why not add a proper separate syscall?

    I think my answer to (a) is one justification for allowing
    process_madvise() to operate on the entire process. Also MADV_DONTNEED
    seems quite suitable for this operation.
    Considering the above answers, are you still leaning towards a separate syscall?

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

    \
     
     \ /
      Last update: 2020-12-23 18:33    [W:2.125 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site