lkml.org 
[lkml]   [2020]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/3] mm,thp,shmem: limit shmem THP alloc gfp_mask
    From
    Date
    On 11/24/20 8:49 PM, Rik van Riel wrote:
    > The allocation flags of anonymous transparent huge pages can be controlled
    > through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can
    > help the system from getting bogged down in the page reclaim and compaction
    > code when many THPs are getting allocated simultaneously.
    >
    > However, the gfp_mask for shmem THP allocations were not limited by those
    > configuration settings, and some workloads ended up with all CPUs stuck
    > on the LRU lock in the page reclaim code, trying to allocate dozens of
    > THPs simultaneously.
    >
    > This patch applies the same configurated limitation of THPs to shmem
    > hugepage allocations, to prevent that from happening.
    >
    > Controlling the gfp_mask of THP allocations through the knobs in
    > sysfs allows users to determine the balance between how aggressively
    > the system tries to allocate THPs at fault time, and how much the
    > application may end up stalling attempting those allocations.
    >
    > This way a THP defrag setting of "never" or "defer+madvise" will result
    > in quick allocation failures without direct reclaim when no 2MB free
    > pages are available.
    >
    > With this patch applied, THP allocations for tmpfs will be a little
    > more aggressive than today for files mmapped with MADV_HUGEPAGE,
    > and a little less aggressive for files that are not mmapped or
    > mapped without that flag.
    >
    > Signed-off-by: Rik van Riel <riel@surriel.com>

    Acked-by: Vlastimil Babka <vbabka@suse.cz>

    \
     
     \ /
      Last update: 2020-11-26 17:58    [W:2.101 / U:0.496 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site