Re: [mm/page_alloc] 7fef431be9: vm-scalability.throughput 87.8% improvement

[David Hildenbrand]

> Am 23.10.2020 um 21:29 schrieb David Rientjes <rientjes@xxxxxxxxxx>:
> 
> On Wed, 21 Oct 2020, kernel test robot wrote:
> 
>> Greeting,
>> 
>> FYI, we noticed a 87.8% improvement of vm-scalability.throughput due to commit:
>> 
>> 
>> commit: 7fef431be9c9ac255838a9578331567b9dba4477 ("mm/page_alloc: place pages to tail in __free_pages_core()")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>> 
>> 
>> in testcase: vm-scalability
>> on test machine: 192 threads Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory
>> with following parameters:
>> 
>>    runtime: 300s
>>    size: 512G
>>    test: anon-wx-rand-mt
>>    cpufreq_governor: performance
>>    ucode: 0x5002f01
>> 
>> test-description: The motivation behind this suite is to exercise functions and regions of the mm/ of the Linux kernel which are of interest to us.
>> test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/
>> 
> 
> I'm curious why we are not able to reproduce this improvement on Skylake 
> and actually see a slight performance degradation, at least for 
> 300s_128G_truncate_throughput.
> 
> Axel Rasmussen <axelrasmussen@xxxxxxxxxx> can provide more details on our 
> results.
> 

As this patch only affects how we first place pages into the freelists when booting up, I‘d be surprised if there would be observable change in actual numbers. Run your system for long enough and it‘s all going to be random in the freelists anyway.

Looks more like random measurement anomalies to me. But maybe there are corner cases where the initial state of the freelists affects a benchmark when run immediately after boot?