lkml.org 
[lkml]   [2019]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch for-5.3 0/4] revert immediate fallback to remote hugepages
On Wed, 4 Sep 2019, Linus Torvalds wrote:

> > This series reverts those reverts and attempts to propose a more sane
> > default allocation strategy specifically for hugepages. Andrea
> > acknowledges this is likely to fix the swap storms that he originally
> > reported that resulted in the patches that removed __GFP_THISNODE from
> > hugepage allocations.
>
> There's no way we can try this for 5.3 even if looks ok. This is
> "let's try this during the 5.4 merge window" material, and see how it
> works.
>
> But I'd love affected people to test this all on their loads and post
> numbers, so that we have actual numbers for this series when we do try
> to merge it.
>

I'm certainly not proposing the last two patches in the series marked as
RFC to be merged. I'm proposing the first two patches in the series,
reverts of the reverts that went into 5.3-rc5, are merged for 5.3 so that
we return to the same behavior that we have had for years and semantics
that MADV_HUGEPAGE has provided that entire libraries and userspaces have
been based on.

It is very clear that there is a path forward here to address the *bug*
that Andrea is reporting: it has become conflated with NUMA allocation
policies which is not at all the issue. Note that if 5.3 is released with
these patches that it requires a very specialized usecase to benefit from:
workloads that are larger than one socket and *requires* remote memory not
being low on memory or fragmented. If remote memory is as low on memory
or fragmented as local memory (like in a datacenter), the reverts that
went into 5.3 will double the impact of the very bug being reported
because now it's causing swap storms for remote memory as well. I don't
anticipate we'll get numbers for that since it's not a configuration they
run in.

The bug here is reclaim in the page allocator that does not benefit memory
compaction because we are failing per-zone watermarks already. The last
two patches in these series avoid that, which is a sane default page
allocation policy, and the allow fallback to remote memory only when we
can't easily allocate locally.

We *need* the ability to allocate hugepages locally if compaction can
work, anything else kills performance. 5.3-rc7 won't try that, it will
simply fallback to remote memory. We need to try compaction but we do not
want to reclaim if failing watermark checks.

I hope that I'm not being unrealistically optimistic that we can make
progress on providing a sane default allocation policy using those last
two patches as a starter for 5.4, but I'm strongly suggesting that you
take the first two patches to return us to the policy that has existed for
years and not allow MADV_HUGEPAGE to be used for immediate remote
allocation when local is possible.

\
 
 \ /
  Last update: 2019-09-05 22:54    [W:0.120 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site