[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210520095119.GA18952@quack2.suse.cz>
Date: Thu, 20 May 2021 11:51:19 +0200
From: Jan Kara <jack@...e.cz>
To: Xing Zhengjun <zhengjun.xing@...ux.intel.com>
Cc: kernel test robot <oliver.sang@...el.com>, Jan Kara <jack@...e.cz>,
Theodore Ts'o <tytso@....edu>,
LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
lkp@...el.com
Subject: Re: [LKP] [ext4] 05c2c00f37: aim7.jobs-per-min -11.8% regression
Hello!
On Thu 20-05-21 15:13:20, Xing Zhengjun wrote:
>
> Do you have time to look at this? The regression still existed in the
> latest Linux mainline v5.13-rc2.
Thanks for verification and for the ping! I had a look into this and I
think the regression is caused by the changes in orphan handling. The load
runs multiple tasks all creating and deleting files. This generally
contends on the orphan locking with fast storage (which is your case
because you use ramdisk as a backing store AFAICT). And the changes I did
move superblock checksum computation under the orphan lock so the lock hold
times are now higher.
Sadly it is not easy to move checksum update from under the orphan lock and
maintain checksum consistency since the checksum has to be recomputed
consistently with the changes of superblock state. But I have one idea how
we could maybe improve the situation. Can you check whether attached patch
recovers the regression? Because that's about how good it could get when we
are more careful when writing out superblock.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
View attachment "0001-ext4-Experiment-with-checksum-computation-during-orp.patch" of type "text/x-patch" (1636 bytes)
Powered by blists - more mailing lists