[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7b2055f2-f5ce-be01-7c39-edcc4be6a7aa@redhat.com>
Date: Mon, 21 Nov 2022 09:00:59 +0100
From: David Hildenbrand <david@...hat.com>
To: kernel test robot <yujie.liu@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com,
Andrew Morton <akpm@...ux-foundation.org>,
Jason Gunthorpe <jgg@...dia.com>,
John Hubbard <jhubbard@...dia.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Hugh Dickins <hughd@...gle.com>, Peter Xu <peterx@...hat.com>,
Alistair Popple <apopple@...dia.com>,
Nadav Amit <namit@...are.com>, Yang Shi <shy828301@...il.com>,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...nel.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
Andrea Parri <parri.andrea@...il.com>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Christoph von Recklinghausen <crecklin@...hat.com>,
Don Dutile <ddutile@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, ying.huang@...el.com, feng.tang@...el.com,
zhengjun.xing@...ux.intel.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [mm] 088b8aa537: vm-scalability.throughput -6.5%
regression
On 21.11.22 04:03, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -6.5% regression of vm-scalability.throughput due to commit:
>
> commit: 088b8aa537c2c767765f1c19b555f21ffe555786 ("mm: fix PageAnonExclusive clearing racing with concurrent RCU GUP-fast")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: vm-scalability
> on test machine: 88 threads 2 sockets Intel(R) Xeon(R) Gold 6238M CPU @ 2.10GHz (Cascade Lake) with 128G memory
> with following parameters:
>
> thp_enabled: never
> thp_defrag: never
> nr_task: 1
> nr_pmem: 2
> priority: 1
> test: swap-w-seq
> cpufreq_governor: performance
>
> 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/
>
Yes, page_try_share_anon_rmap() might now be a bit more expensive now,
turning try_to_unmap_one() a bit more expensive. However, that patch
also changes the unconditional TLB flush into a conditional TLB flush,
so results might vary heavily between machines/architectures.
smp_mb__after_atomic() is a NOP on x86, so the smp_mb() before the
page_maybe_dma_pinned() check would have to be responsible.
While there might certainly be ways for optimizing that further (e.g.,
if the ptep_get_and_clear() already implies a smp_mb()), the facts that:
(1) It's a swap micro-benchmark
(2) We have 3% stddev
Don't make me get active now ;)
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists