Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7b2055f2-f5ce-be01-7c39-edcc4be6a7aa@redhat.com>
Date:   Mon, 21 Nov 2022 09:00:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
To:     kernel test robot <yujie.liu@intel.com>
Cc:     oe-lkp@lists.linux.dev, lkp@intel.com,
        Andrew Morton <akpm@linux-foundation.org>,
        Jason Gunthorpe <jgg@nvidia.com>,
        John Hubbard <jhubbard@nvidia.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Hugh Dickins <hughd@google.com>, Peter Xu <peterx@redhat.com>,
        Alistair Popple <apopple@nvidia.com>,
        Nadav Amit <namit@vmware.com>, Yang Shi <shy828301@gmail.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Michal Hocko <mhocko@kernel.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Andrea Parri <parri.andrea@gmail.com>,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Christoph von Recklinghausen <crecklin@redhat.com>,
        Don Dutile <ddutile@redhat.com>, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, ying.huang@intel.com, feng.tang@intel.com,
        zhengjun.xing@linux.intel.com, fengwei.yin@intel.com
References: <202211211037.2b2e5e1f-yujie.liu@intel.com>
Content-Language: en-US
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
Subject: Re: [linus:master] [mm] 088b8aa537: vm-scalability.throughput -6.5%
 regression
In-Reply-To: <202211211037.2b2e5e1f-yujie.liu@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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