From: Ritesh Harjani <riteshh@linux.ibm.com>
To: kernel test robot <rong.a.chen@intel.com>,
Xing Zhengjun <zhengjun.xing@linux.intel.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
kbuild test robot <lkp@intel.com>, Jan Kara <jack@suse.cz>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
lkp@lists.01.org
Subject: Re: [ext4] d3b6f23f71: stress-ng.fiemap.ops_per_sec -60.5% regression
Date: Wed, 15 Jul 2020 16:34:36 +0530 [thread overview]
Message-ID: <20200715110437.7D0A3AE051@d06av26.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <20200407080036.GA8179@shao2-debian>
Hello Xing,
On 4/7/20 1:30 PM, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -60.5% regression of stress-ng.fiemap.ops_per_sec due to commit:
>
>
> commit: d3b6f23f71670007817a5d59f3fbafab2b794e8c ("ext4: move ext4_fiemap to use iomap framework")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: stress-ng
> on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 192G memory
> with following parameters:
>
> nr_threads: 10%
> disk: 1HDD
> testtime: 1s
> class: os
> cpufreq_governor: performance
> ucode: 0x500002c
> fs: ext4
I started looking into this issue. But with my unit testing, I didn't
find any perf issue with fiemap ioctl call. I haven't yet explored about
how stress-ng take fiemap performance numbers, it could be doing
something differently. But in my testing I just made sure to create a
file with large number of extents and used xfs_io -c "fiemap -v" cmd
to check how much time it takes to read all the entries in 1st
and subsequent iterations.
Setup comprised of qemu machine on x86_64 with latest linux branch.
1. created a file of 10G using fallocate. (this allocated unwritten
extents for this file).
2. Then I punched hole on every alternate block of file. This step took
a long time. And after sufficiently long time, I had to cancel it.
for i in $(seq 1 2 xxxxx); do echo $i; fallocate -p -o $(($i*4096)) -l
4096; done
3. Then issued fiemap call via xfs_io and took the time measurement.
time xfs_io -c "fiemap -v" bigfile > /dev/null
Perf numbers on latest default kernel build for above cmd.
1st iteration
==============
real 0m31.684s
user 0m1.593s
sys 0m24.174s
2nd and subsequent iteration
============================
real 0m3.379s
user 0m1.300s
sys 0m2.080s
4. Then I reverted all the iomap_fiemap patches and re-tested this.
With this the older ext4_fiemap implementation will be tested:-
1st iteration
==============
real 0m31.591s
user 0m1.400s
sys 0m24.243s
2nd and subsequent iteration (had to cancel it since it was taking more
time then 15m)
============================
^C^C
real 15m49.884s
user 0m0.032s
sys 15m49.722s
I guess the reason why 2nd iteration with older implementation is taking
too much time is since with previous implementation we never cached
extent entries in extent_status tree. And also in 1st iteration the page
cache may get filled with lot of buffer_head entries. So maybe page
reclaims are taking more time.
While with the latest implementation using iomap_fiemap(), the call to
query extent blocks is done using ext4_map_blocks(). ext4_map_blocks()
by default will also cache the extent entries into extent_status tree.
Hence during 2nd iteration, we will directly read the entries from
extent_status tree and will not do any disk I/O.
-ritesh
next prev parent reply other threads:[~2020-07-15 11:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 8:00 [ext4] d3b6f23f71: stress-ng.fiemap.ops_per_sec -60.5% regression kernel test robot
2020-04-07 8:00 ` kernel test robot
2020-04-13 8:37 ` [LKP] " Xing Zhengjun
2020-04-13 8:37 ` Xing Zhengjun
2020-04-13 10:56 ` [LKP] " Ritesh Harjani
2020-04-14 5:49 ` Xing Zhengjun
2020-04-14 5:49 ` Xing Zhengjun
2020-06-16 7:13 ` [LKP] " Xing Zhengjun
2020-06-16 7:13 ` Xing Zhengjun
2020-07-15 11:04 ` Ritesh Harjani [this message]
2020-07-22 6:17 ` Xing Zhengjun
2020-08-19 1:52 ` [LKP] " Xing Zhengjun
2020-08-19 1:52 ` Xing Zhengjun
2020-08-19 17:49 ` [LKP] " Theodore Y. Ts'o
2020-08-19 17:49 ` Theodore Y. Ts'o
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=20200715110437.7D0A3AE051@d06av26.portsmouth.uk.ibm.com \
--to=riteshh@linux.ibm.com \
--cc=darrick.wong@oracle.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=rong.a.chen@intel.com \
--cc=tytso@mit.edu \
--cc=zhengjun.xing@linux.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.