All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever III <chuck.lever@oracle.com>
To: Frank van der Linden <fllinden@amazon.com>,
	Wang Yugui <wangyugui@e16-tech.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Matthew Wilcox <matthew.wilcox@oracle.com>,
	Liam Howlett <liam.howlett@oracle.com>
Subject: Re: filecache LRU performance regression
Date: Wed, 1 Jun 2022 00:34:34 +0000	[thread overview]
Message-ID: <BED36887-054D-4DC9-A5F1-CB6DD1F0DC16@oracle.com> (raw)
In-Reply-To: <ADD1751A-7F67-4729-BFFC-D6938CA963A0@oracle.com>



> On May 27, 2022, at 5:34 PM, Chuck Lever III <chuck.lever@oracle.com> wrote:
> 
> 
> 
>> On May 27, 2022, at 4:37 PM, Frank van der Linden <fllinden@amazon.com> wrote:
>> 
>> On Fri, May 27, 2022 at 06:59:47PM +0000, Chuck Lever III wrote:
>>> 
>>> 
>>> Hi Frank-
>>> 
>>> Bruce recently reminded me about this issue. Is there a bugzilla somewhere?
>>> Do you have a reproducer I can try?
>> 
>> Hi Chuck,
>> 
>> The easiest way to reproduce the issue is to run generic/531 over an
>> NFSv4 mount, using a system with a larger number of CPUs on the client
>> side (or just scaling the test up manually - it has a calculation based
>> on the number of CPUs).
>> 
>> The test will take a long time to finish. I initially described the
>> details here:
>> 
>> https://lore.kernel.org/linux-nfs/20200608192122.GA19171@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com/
>> 
>> Since then, it was also reported here:
>> 
>> https://lore.kernel.org/all/20210531125948.2D37.409509F4@e16-tech.com/T/#m8c3e4173696e17a9d5903d2a619550f352314d20
> 
> Thanks for the summary. So, there isn't a bugzilla tracking this
> issue? If not, please create one here:
> 
>  https://bugzilla.linux-nfs.org/
> 
> Then we don't have to keep asking for a repeat summary ;-)

I can easily reproduce this scenario in my lab. I've opened:

  https://bugzilla.linux-nfs.org/show_bug.cgi?id=386


--
Chuck Lever




  parent reply	other threads:[~2022-06-01  0:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-27 18:59 filecache LRU performance regression Chuck Lever III
2022-05-27 20:37 ` Frank van der Linden
2022-05-27 21:34   ` Chuck Lever III
2022-05-29  2:32     ` Wang Yugui
2022-05-29 16:58       ` Chuck Lever III
2022-05-30  1:36         ` Wang Yugui
2022-06-01  0:34     ` Chuck Lever III [this message]
2022-06-01 16:10       ` Frank van der Linden
2022-06-01 16:37         ` Chuck Lever III
2022-06-01 21:18           ` Frank van der Linden
2022-06-01 21:37             ` Chuck Lever III
2022-06-01 23:05             ` J. Bruce Fields
2022-06-02  1:49           ` Wang Yugui
2022-06-04 15:44             ` Chuck Lever III
2022-06-04 16:14               ` Wang Yugui

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=BED36887-054D-4DC9-A5F1-CB6DD1F0DC16@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=fllinden@amazon.com \
    --cc=liam.howlett@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=matthew.wilcox@oracle.com \
    --cc=wangyugui@e16-tech.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.