Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   David Hildenbrand <david@redhat.com>
Mime-Version: 1.0 (1.0)
Subject: Re: [mm/page_alloc] 7fef431be9: vm-scalability.throughput 87.8% improvement
Date:   Fri, 23 Oct 2020 21:46:18 +0200
Message-Id: <9F5E9E0C-A367-49EE-8764-58555C742F1E@redhat.com>
References: <alpine.DEB.2.23.453.2010231226310.1686635@chino.kir.corp.google.com>
Cc:     kernel test robot <rong.a.chen@intel.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Kevin Ko <kevko@google.com>,
        David Hildenbrand <david@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        Oscar Salvador <osalvador@suse.de>,
        Wei Yang <richard.weiyang@linux.alibaba.com>,
        Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
        Michal Hocko <mhocko@suse.com>,
        Alexander Duyck <alexander.h.duyck@linux.intel.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Dave Hansen <dave.hansen@intel.com>,
        Mike Rapoport <rppt@kernel.org>,
        "K. Y. Srinivasan" <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>,
        Matthew Wilcox <willy@infradead.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Michal Hocko <mhocko@kernel.org>,
        Scott Cheloha <cheloha@linux.ibm.com>,
        LKML <linux-kernel@vger.kernel.org>, lkp@lists.01.org,
        lkp@intel.com, ying.huang@intel.com, feng.tang@intel.com,
        zhengjun.xing@intel.com
In-Reply-To: <alpine.DEB.2.23.453.2010231226310.1686635@chino.kir.corp.google.com>
To:     David Rientjes <rientjes@google.com>
Precedence: bulk


> Am 23.10.2020 um 21:29 schrieb David Rientjes <rientjes@google.com>:
>=20
> =EF=BB=BFOn Wed, 21 Oct 2020, kernel test robot wrote:
>=20
>> Greeting,
>>=20
>> FYI, we noticed a 87.8% improvement of vm-scalability.throughput due to c=
ommit:
>>=20
>>=20
>> commit: 7fef431be9c9ac255838a9578331567b9dba4477 ("mm/page_alloc: place p=
ages to tail in __free_pages_core()")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>=20
>>=20
>> in testcase: vm-scalability
>> on test machine: 192 threads Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz=
 with 192G memory
>> with following parameters:
>>=20
>>    runtime: 300s
>>    size: 512G
>>    test: anon-wx-rand-mt
>>    cpufreq_governor: performance
>>    ucode: 0x5002f01
>>=20
>> test-description: The motivation behind this suite is to exercise functio=
ns 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/
>>=20
>=20
> I'm curious why we are not able to reproduce this improvement on Skylake=20=

> and actually see a slight performance degradation, at least for=20
> 300s_128G_truncate_throughput.
>=20
> Axel Rasmussen <axelrasmussen@google.com> can provide more details on our=20=

> results.
>=20

As this patch only affects how we first place pages into the freelists when b=
ooting up, I=E2=80=98d be surprised if there would be observable change in a=
ctual numbers. Run your system for long enough and it=E2=80=98s all going to=
 be random in the freelists anyway.

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