lkml.org 
[lkml]   [2019]   [Sep]   [7]   [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 Sat, 7 Sep 2019, Linus Torvalds wrote:

> > Andrea acknowledges the swap storm that he reported would be fixed with
> > the last two patches in this series
>
> The problem is that even you aren't arguing that those patches should
> go into 5.3.
>

For three reasons: (a) we lack a test result from Andrea, (b) there's
on-going discussion, particularly based on Vlastimil's feedback, and
(c) the patches will be refreshed incorporating that feedback as well as
Mike's suggestion to exempt __GFP_RETRY_MAYFAIL for hugetlb.

> So those fixes aren't going in, so "the swap storms would be fixed"
> argument isn't actually an argument at all as far as 5.3 is concerned.
>

It indicates that progress has been made to address the actual bug without
introducing long-lived access latency regressions for others, particularly
those who use MADV_HUGEPAGE. In the worst case, some systems running
5.3-rc4 and 5.3-rc5 have the same amount of memory backed by hugepages but
on 5.3-rc5 the vast majority of it is allocated remotely. This incurs a
signficant performance regression regardless of platform; the only thing
needed to induce this is a fragmented local node that would otherwise be
compacted in 5.3-rc4 rather than quickly allocate remote on 5.3-rc5.

> End result: we'd have the qemu-kvm instance performance problem in 5.3
> that apparently causes distros to apply those patches that you want to
> revert anyway.
>
> So reverting would just make distros not use 5.3 in that form.
>

I'm arguing to revert 5.3 back to the behavior that we have had for years
and actually fix the bug that everybody else seems to be ignoring and then
*backport* those fixes to 5.3 stable and every other stable tree that can
use them. Introducing a new mempolicy for NUMA locality into 5.3.0 that
will subsequently changed in future 5.3 stable kernels and differs from
all kernels from the past few years is not in anybody's best interest if
the actual problem can be fixed. It requires more feedback than a
one-line "the swap storms would be fixed with this." That collaboration
takes time and isn't something that should be rushed into 5.3-rc5.

Yes, we can fix NUMA locality of hugepages when a workload like qemu is
larger than a single socket; the vast majority of workloads in the
datacenter are small than a socket and *cannot* incur the performance
penalty if local memory is fragmented that 5.3-rc5 introduces.

In other words, 5.3-rc5 is only fixing a highly specialized usecase where
remote allocation is acceptable because the workload is larger than a
socket *and* remote memory is not low on memory or fragmented. If you
consider the opposite of that, workloads smaller than a socket or local
compaction actually works, this has introduced a measurable regression for
everybody else.

I'm not sure why we are ignoring a painfully obvious bug in the page
allocator because of a poor feedback loop between itself and memory
compaction and rather papering over it by falling back to remote memory
when NUMA actually does matter. If you release 5.3 without the first two
patches in this series, I wouldn't expect any additional feedback or test
results to fix this bug considering all we have gotten so far is "this
would fix this swap storms" and not collaborating to fix the issue for
everybody rather than only caring about their own workloads. At least my
patches acknowledge and try to fix the issue the other is encountering.

\
 
 \ /
  Last update: 2019-09-08 03:52    [W:0.100 / U:7.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site