From: Mike Kravetz <mike.kravetz@oracle.com>
To: kernel test robot <oliver.sang@intel.com>
Cc: oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Ackerley Tng <ackerleytng@google.com>,
Erdem Aktas <erdemaktas@google.com>,
Matthew Wilcox <willy@infradead.org>,
Muchun Song <songmuchun@bytedance.com>,
Sidhartha Kumar <sidhartha.kumar@oracle.com>,
Vishal Annapurve <vannapurve@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-fsdevel@vger.kernel.org, ying.huang@intel.com,
feng.tang@intel.com, fengwei.yin@intel.com
Subject: Re: [linus:master] [page cache] 9425c591e0: vm-scalability.throughput -20.0% regression
Date: Wed, 21 Jun 2023 08:28:54 -0700 [thread overview]
Message-ID: <20230621152854.GA4155@monkey> (raw)
In-Reply-To: <202306211346.1e9ff03e-oliver.sang@intel.com>
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
next prev parent reply other threads:[~2023-06-21 15:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 7:19 [linus:master] [page cache] 9425c591e0: vm-scalability.throughput -20.0% regression kernel test robot
2023-06-21 15:28 ` Mike Kravetz [this message]
2023-06-26 9:05 ` Yin, Fengwei
2023-06-27 4:38 ` Yin Fengwei
2023-06-23 12:36 ` Linux regression tracking #adding (Thorsten Leemhuis)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230621152854.GA4155@monkey \
--to=mike.kravetz@oracle.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=erdemaktas@google.com \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=sidhartha.kumar@oracle.com \
--cc=songmuchun@bytedance.com \
--cc=vannapurve@google.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.