Messages in this thread | | | Subject | Re: [PATCH 1/3] mm,thp,shmem: limit shmem THP alloc gfp_mask | From | Vlastimil Babka <> | Date | Thu, 26 Nov 2020 17:56:47 +0100 |
| |
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>
| |