Re: [PATCH v4] mm,thp,shmem: limit shmem THP alloc gfp_mask

[Rik van Riel <riel@surriel.com>]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

On Sat, 2020-10-24 at 03:09 +0100, Matthew Wilcox wrote:
> On Fri, Oct 23, 2020 at 08:48:04PM -0400, 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.
> > 
> > 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.
> 
> How about this code path though?
> 
> shmem_get_pages() [ in i915 ]
>   shmem_read_mapping_page_gfp(__GFP_NORETRY | __GFP_NOWARN)
>     shmem_getpage_gfp()
>       shmem_alloc_and_acct_page()
>         shmem_alloc_hugepage()
> 
> I feel like the NORETRY from i915 should override whatever is set
> in sysfs for anon THPs.  What do others think?

It looks like currently the only way to get a THP
allocation with __GFP_DIRECT_RECLAIM and without
__GFP_NORETRY (which does nothing without
__GFP_DIRECT_RECLAIM) is to explicitly do an
madvise MADV_HUGEPAGE on a VMA.

I am not convinced the i915 driver should
override a userspace madvise.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]