Messages in this thread | | | Subject | Re: [PATCH 1/2] mm,thp,shmem: limit shmem THP alloc gfp_mask | From | Rik van Riel <> | Date | Fri, 13 Nov 2020 22:44:20 -0500 |
| |
On Thu, 2020-11-12 at 11:52 +0100, Michal Hocko wrote: > On Thu 05-11-20 14:15:07, Rik van Riel wrote: > > > > This patch applies the same configurated limitation of THPs to > > shmem > > hugepage allocations, to prevent that from happening. > > I believe you should also exaplain why we want to control defrag by > the > global knob while the enable logic is per mount.
I added that to the changelog for the next version of the patches.
> > 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. > > This begs some numbers. A little is rather bad unit of performance. I > do > agree that unifying those makes sense in general though.
The aggressiveness is in changes to the gfp_mask, eg by adding __GFP_NORETRY. How that translates into THP allocation success rates is entirely dependent on the workload and on what else is in memory at the time.
I am not sure any numbers I could gather will be representative for anything but the workloads I am testing.
However, I did find an issue in hugepage_vma_check that prevents khugepaged from collapsing pages on shmem filesystems mounted with huge=always or huge=within_size when transparent_hugepage/enabled is set to [madvise].
The next version of the series will have a third patch, in order to fix that.
-- All Rights Reversed. [unhandled content-type:application/pgp-signature] | |