[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230621152854.GA4155@monkey>
Date: Wed, 21 Jun 2023 08:28:54 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Ackerley Tng <ackerleytng@...gle.com>,
Erdem Aktas <erdemaktas@...gle.com>,
Matthew Wilcox <willy@...radead.org>,
Muchun Song <songmuchun@...edance.com>,
Sidhartha Kumar <sidhartha.kumar@...cle.com>,
Vishal Annapurve <vannapurve@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-fsdevel@...r.kernel.org, ying.huang@...el.com,
feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [page cache] 9425c591e0:
vm-scalability.throughput -20.0% regression
On 06/21/23 15:19, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed a -20.0% regression of vm-scalability.throughput on:
>
>
> commit: 9425c591e06a9ab27a145ba655fb50532cf0bcc9 ("page cache: fix page_cache_next/prev_miss off by one")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> testcase: vm-scalability
> test machine: 96 threads 2 sockets Intel(R) Xeon(R) Platinum 8260L CPU @ 2.40GHz (Cascade Lake) with 128G memory
> parameters:
>
> runtime: 300s
> test: lru-file-readonce
> 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/
>
> In addition to that, the commit also has significant impact on the following tests:
>
> +------------------+----------------------------------------------------------------------------------------------------+
> | testcase: change | vm-scalability: vm-scalability.throughput -18.9% regression |
> | test machine | 96 threads 2 sockets Intel(R) Xeon(R) Platinum 8260L CPU @ 2.40GHz (Cascade Lake) with 128G memory |
> | test parameters | cpufreq_governor=performance |
> | | debug-setup=no-monitor |
> | | runtime=300s |
> | | test=lru-file-readonce |
> +------------------+----------------------------------------------------------------------------------------------------+
> | testcase: change | vm-scalability: vm-scalability.throughput -52.8% regression |
> | test machine | 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory |
> | test parameters | cpufreq_governor=performance |
> | | runtime=300s |
> | | test=lru-file-readonce |
> +------------------+----------------------------------------------------------------------------------------------------+
> | testcase: change | vm-scalability: vm-scalability.throughput -54.0% regression |
> | test machine | 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory |
> | test parameters | cpufreq_governor=performance |
> | | debug-setup=no-monitor |
> | | runtime=300s |
> | | test=lru-file-readonce |
> +------------------+----------------------------------------------------------------------------------------------------+
>
Ouch!
I suspected this change could impact page_cache_next/prev_miss users, but had
no idea how much.
Unless someone sees something wrong in 9425c591e06a, the best approach
might be to revert and then add a simple interface to check for 'folio at
a given index in the cache' as suggested by Ackerley Tng.
https://lore.kernel.org/linux-mm/98624c2f481966492b4eb8272aef747790229b73.1683069252.git.ackerleytng@google.com/
--
Mike Kravetz
Powered by blists - more mailing lists