On 09/05/2018 09:08 AM, Michal Hocko wrote: > On Tue 04-09-18 23:44:03, Andrea Arcangeli wrote: > [...] >> That kind of swapping may only pay off in the very long long term, >> which is what khugepaged is for. khugepaged already takes care of the >> long term, so we could later argue and think if khugepaged should >> swapout or not in such condition, but I don't think there's much to >> argue about the page fault. > > I agree that defrag==always doing a reclaim is not really good and > benefits are questionable. If you remember this was the primary reason > why the default has been changed. > >>> Thanks for your and Stefan's testing. I will wait for some more >>> feedback. I will be offline next few days and if there are no major >>> objections I will repost with both tested-bys early next week. >> >> I'm not so positive about 2 of the above tests if I understood the >> test correctly. >> >> Those results are totally fine if you used the non default memory >> policy, but with MPOL_DEFAULT and in turn no hard bind of the memory, >> I'm afraid it'll be even be harder to reproduce when things will go >> wrong again in those two cases. > > We can and should think about this much more but I would like to have > this regression closed. So can we address GFP_THISNODE part first and > build more complex solution on top? > > Is there any objection to my patch which does the similar thing to your > patch v2 in a different location? Similar but not the same. It fixes the madvise case, but I wonder about the no-madvise defrag=defer case, where Zi Yan reports it still causes swapping.
