Is there any objection from anybody to applying the first two patches, the reverts of the reverts that went into 5.3-rc5, for 5.3 and pursuing discussion and development using the last two patches in this series as a starting point for a sane allocation policy that just works by default for everybody? Andrea acknowledges the swap storm that he reported would be fixed with the last two patches in this series and there has been discussion on how they can be extended at the same time that they do not impact allocations outside the scope of the discussion here (hugetlb). On Thu, 5 Sep 2019, David Rientjes wrote: > 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. >
