thp nodereclaim fixes
Status from this message: Nacked-by: David Rientjes <[email protected]>
Get series with b4
b4 am [email protected]Versions newest first
Patches in v1
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappingsmm/ | +30 | 45 replies | |
| 2/2 | mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmaskinclude/ include/ mm/ +2 more | +40 | 19 replies |
Reviews trailers per patch
All 2 patches have a Reviewed-by or Acked-by.
| Patch | Andrea Arcangeli | Mel Gorman | David Rientjes | Vlastimil Babka |
|---|---|---|---|---|
| 1/2 | Debugged-by | R-b | Nacked-by | |
| 2/2 | A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 4 reviewers.
Cover letter [PATCH 0/2] thp nodereclaim fixes
Hi,
this has been brought up by Andrea [1] and he proposed two different fixes for the regression. I have proposed an alternative fix [2]. I have changed my mind in the end because whatever fix we end up with it should be backported to the stable trees so going with a minimalistic one is preferred so I have got back to the Andrea's second proposed solution
[3] in the end. I have just reworded the changelog to reflect other bug report with the stall information.
My primary concern about [3] was that the __GFP_THISNODE logic should be placed in alloc_hugepage_direct_gfpmask which I've done on top of the fix as a cleanup (patch 2) and it doesn't need to be backported to the stable tree.
I am still not happy that the David's workload will regress as a result but we should really focus on the default behavior and come with a more robust solution for specialized one for those who have more restrictive NUMA preferences. I am thinking about a new numa policy that would mimic node reclaim behavior and I am willing to work on that but we really have to fix the regression first and that is the patch 1.
Thoughts, alternative patches?
[1] http://lkml.kernel.org/r/[email protected]
[2] http://lkml.kernel.org/r/[email protected]
[3] http://lkml.kernel.org/r/[email protected]