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.
Attachment:
signature.asc
Description: This is a digitally signed message part
