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
>> <[email protected]> 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
>>
>
