Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression

[Vlastimil Babka]

On 11/27/18 8:05 PM, Vlastimil Babka wrote:
> On 11/27/18 6:08 PM, Linus Torvalds wrote:
>> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
>> <rong.a.chen@xxxxxxxxx> wrote:
>>>
>>> FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>>> to commit ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
>>> MADV_HUGEPAGE mappings")
>>
>> Well, that's certainly noticeable and not good.
>>
>> Andrea, I suspect it might be causing fights with auto numa migration..
>>
>> Lots more system time, but also look at this:
>>
>>>    1122389 Â  9%     +17.2%    1315380 Â  4%  proc-vmstat.numa_hit
>>>     214722 Â  5%     +21.6%     261076 Â  3%  proc-vmstat.numa_huge_pte_updates
>>>    1108142 Â  9%     +17.4%    1300857 Â  4%  proc-vmstat.numa_local
>>>     145368 Â 48%     +63.1%     237050 Â 17%  proc-vmstat.numa_miss
>>>     159615 Â 44%     +57.6%     251573 Â 16%  proc-vmstat.numa_other
>>>     185.50 Â 81%   +8278.6%      15542 Â 40%  proc-vmstat.numa_pages_migrated
>>
>> Should the commit be reverted? Or perhaps at least modified?
> 
> This part of the test's config is important:
> 
> thp_defrag: always
> 
> While the commit targets MADV_HUGEPAGE mappings (such as Andrea's
> kvm-qemu usecase), with defrag=always, all mappings behave almost as a
> MADV_HUGEPAGE mapping. That's no longer a default for some years now and

Specifically, that's 444eb2a449ef ("mm: thp: set THP defrag by default
to madvise and add a stall-free defrag option") merged in v4.5. So we
might actually hit this regression with 4.4 stable backport...

> I think nobody recommends it. In the default configuration nothing
> changes for non-madvise mappings.
> 
> Vlastimil
> 
>>                      Linus
>>
>