All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>,
	kernel test robot <rong.a.chen@intel.com>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	Ritesh Harjani <riteshh@linux.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	lkp@lists.01.org
Subject: Re: [ext4] b1b4705d54: filebench.sum_bytes_mb/s -20.2% regression
Date: Tue, 7 Jan 2020 18:28:24 +0100	[thread overview]
Message-ID: <20200107172824.GK25547@quack2.suse.cz> (raw)
In-Reply-To: <20200107165708.GA3619@mit.edu>

On Tue 07-01-20 11:57:08, Theodore Y. Ts'o wrote:
> On Tue, Jan 07, 2020 at 02:41:06PM +0100, Jan Kara wrote:
> > Hello,
> > 
> > On Tue 24-12-19 08:59:15, kernel test robot wrote:
> > > FYI, we noticed a -20.2% regression of filebench.sum_bytes_mb/s due to commit:
> > > 
> > > 
> > > commit: b1b4705d54abedfd69dcdf42779c521aa1e0fbd3 ("ext4: introduce direct I/O read using iomap infrastructure")
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > > 
> > > in testcase: filebench
> > > on test machine: 8 threads Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 8G memory
> > > with following parameters:
> > > 
> > > 	disk: 1HDD
> > > 	fs: ext4
> > > 	test: fivestreamreaddirect.f
> > > 	cpufreq_governor: performance
> > > 	ucode: 0x27
> > 
> > I was trying to reproduce this but I failed with my test VM. I had SATA SSD
> > as a backing store though so maybe that's what makes a difference. Maybe
> > the new code results in somewhat more seeks because the five threads which
> > compete in submitting sequential IO end up being more interleaved?
> 
> A "-20.2% regression" should be read as a "20.2% performance
> improvement" is zero-day kernel speak.

Are you sure? I can see:

     58.30 ±  2%     -20.2%      46.53        filebench.sum_bytes_mb/s

which implies to me previously the throughput was 58 MB/s and after the
commit it was 46 MB/s?

Anyway, in my testing that commit made no difference in that benchmark
whasoever (getting around 97 MB/s for each thread before and after the
commit).
 
								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: lkp@lists.01.org
Subject: Re: [ext4] b1b4705d54: filebench.sum_bytes_mb/s -20.2% regression
Date: Tue, 07 Jan 2020 18:28:24 +0100	[thread overview]
Message-ID: <20200107172824.GK25547@quack2.suse.cz> (raw)
In-Reply-To: <20200107165708.GA3619@mit.edu>

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

On Tue 07-01-20 11:57:08, Theodore Y. Ts'o wrote:
> On Tue, Jan 07, 2020 at 02:41:06PM +0100, Jan Kara wrote:
> > Hello,
> > 
> > On Tue 24-12-19 08:59:15, kernel test robot wrote:
> > > FYI, we noticed a -20.2% regression of filebench.sum_bytes_mb/s due to commit:
> > > 
> > > 
> > > commit: b1b4705d54abedfd69dcdf42779c521aa1e0fbd3 ("ext4: introduce direct I/O read using iomap infrastructure")
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > > 
> > > in testcase: filebench
> > > on test machine: 8 threads Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 8G memory
> > > with following parameters:
> > > 
> > > 	disk: 1HDD
> > > 	fs: ext4
> > > 	test: fivestreamreaddirect.f
> > > 	cpufreq_governor: performance
> > > 	ucode: 0x27
> > 
> > I was trying to reproduce this but I failed with my test VM. I had SATA SSD
> > as a backing store though so maybe that's what makes a difference. Maybe
> > the new code results in somewhat more seeks because the five threads which
> > compete in submitting sequential IO end up being more interleaved?
> 
> A "-20.2% regression" should be read as a "20.2% performance
> improvement" is zero-day kernel speak.

Are you sure? I can see:

     58.30 ±  2%     -20.2%      46.53        filebench.sum_bytes_mb/s

which implies to me previously the throughput was 58 MB/s and after the
commit it was 46 MB/s?

Anyway, in my testing that commit made no difference in that benchmark
whasoever (getting around 97 MB/s for each thread before and after the
commit).
 
								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2020-01-07 17:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-24  0:59 [ext4] b1b4705d54: filebench.sum_bytes_mb/s -20.2% regression kernel test robot
2019-12-24  0:59 ` kernel test robot
2020-01-07 13:41 ` Jan Kara
2020-01-07 13:41   ` Jan Kara
2020-01-07 16:57   ` Theodore Y. Ts'o
2020-01-07 16:57     ` Theodore Y. Ts'o
2020-01-07 17:28     ` Jan Kara [this message]
2020-01-07 17:28       ` Jan Kara
2020-01-08  2:31       ` Rong Chen
2020-01-08  2:31         ` Rong Chen
2020-03-04  8:15         ` [LKP] " Xing Zhengjun
2020-03-04  8:15           ` Xing Zhengjun
2020-03-25  5:50           ` [LKP] " Xing Zhengjun
2020-03-25  5:50             ` Xing Zhengjun
2020-03-25 14:31             ` [LKP] " Jan Kara
2020-03-25 14:31               ` Jan Kara
2020-04-15  7:55               ` [LKP] " Xing Zhengjun
2020-04-15  7:55                 ` Xing Zhengjun
2020-04-15  8:39                 ` [LKP] " Jan Kara
2020-04-15  8:39                   ` Jan Kara
2020-04-16  5:48                   ` [LKP] " Xing Zhengjun
2020-04-16  5:48                     ` Xing Zhengjun

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=20200107172824.GK25547@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@lists.01.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=riteshh@linux.ibm.com \
    --cc=rong.a.chen@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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.