On Fri 13-11-20 22:44:20, Rik van Riel wrote: > 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. Yes and that is why I would argue about consistency with THP rather than put claims that hard to back by numbers. -- Michal Hocko SUSE Labs
