Re: [rfc] mm, hugetlb: allow hugepage allocations to excessively reclaim

[David Rientjes <rientjes@google.com>]

On Thu, 3 Oct 2019, Vlastimil Babka wrote:

> I think the key differences between Mike's tests and Michal's is this part
> from Mike's mail linked above:
> 
> "I 'tested' by simply creating some background activity and then seeing
> how many hugetlb pages could be allocated. Of course, many tries over
> time in a loop."
> 
> - "some background activity" might be different than Michal's pre-filling
>   of the memory with (clean) page cache
> - "many tries over time in a loop" could mean that kswapd has time to 
>   reclaim and eventually the new condition for pageblock order will pass
>   every few retries, because there's enough memory for compaction and it
>   won't return COMPACT_SKIPPED
> 

I'll rely on Mike, the hugetlb maintainer, to assess the trade-off between 
the potential for encountering very expensive reclaim as Andrea did and 
the possibility of being able to allocate additional hugetlb pages at 
runtime if we did that expensive reclaim.

For parity with previous kernels it seems reasonable to ask that this 
remains unchanged since allocating large amounts of hugetlb pages has 
different latency expectations than during page fault.  This patch is 
available if he'd prefer to go that route.

On the other hand, userspace could achieve similar results if it were to 
use vm.drop_caches and explicitly triggered compaction through either 
procfs or sysfs before writing to vm.nr_hugepages, and that would be much 
faster because it would be done in one go.  Users who allocate through the 
kernel command line would obviously be unaffected.

Commit b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when 
compaction may not succeed") was written with the latter in mind.  Mike 
subsequently requested that hugetlb not be impacted at least provisionally 
until it could be further assessed.

I'd suggest that latter: let the user initiate expensive reclaim and/or 
compaction when tuning vm.nr_hugepages and leave no surprises for users 
using hugetlb overcommit, but I wouldn't argue against either approach, he 
knows the users and expectations of hugetlb far better than I do.