lkml.org 
[lkml]   [2021]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] mm: split thp synchronously on MADV_DONTNEED
    From
    >> I do wonder which purpose the deferred split serves nowadays at all.
    >> Fortunately, there is documentation: Documentation/vm/transhuge.rst:
    >>
    >> "
    >> Unmapping part of THP (with munmap() or other way) is not going to free
    >> memory immediately. Instead, we detect that a subpage of THP is not in
    >> use in page_remove_rmap() and queue the THP for splitting if memory
    >> pressure comes. Splitting will free up unused subpages.
    >>
    >> Splitting the page right away is not an option due to locking context in
    >> the place where we can detect partial unmap. It also might be
    >> counterproductive since in many cases partial unmap happens during
    >> exit(2) if a THP crosses a VMA boundary.
    >>
    >> The function deferred_split_huge_page() is used to queue a page for
    >> splitting. The splitting itself will happen when we get memory pressure
    >> via shrinker interface.
    >> "
    >>
    >> I do wonder which these locking contexts are exactly, and if we could
    >> also do the same thing on ordinary munmap -- because I assume it can be
    >> similarly problematic for some applications.
    >
    > This is a good question regarding munmap. One main difference is
    > munmap takes mmap_lock in write mode and usually performance critical
    > applications avoid such operations.

    Maybe we can extend it too most page zapping, if that makes things simpler.

    >
    >> The "exit()" case might
    >> indeed be interesting, but I really do wonder if this is even observable
    >> in actual number: I'm not so sure about the "many cases" but I might be
    >> wrong, of course.
    >
    > I am not worried about the exit(). The whole THP will get freed and be
    > removed from the deferred list as well. Note that deferred list does
    > not hold reference to the THP and has a hook in the THP destructor.

    Yes, you're right. We'll run into the de-constructor either way.

    --
    Thanks,

    David / dhildenb

    \
     
     \ /
      Last update: 2021-11-23 17:57    [W:4.102 / U:0.260 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site