All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <rong.a.chen@intel.com>
To: dsterba@suse.cz, Johannes Thumshirn <jthumshirn@suse.de>,
	lkp@01.org, Linus Torvalds <torvalds@linux-foundation.org>,
	Nikolay Borisov <nborisov@suse.com>, WenRuo Qu <wqu@suse.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [btrfs] 2996e1f8bc: aim7.jobs-per-min -13.2% regression
Date: Thu, 30 May 2019 21:32:15 +0800	[thread overview]
Message-ID: <20190530133215.GC22325@shao2-debian> (raw)
In-Reply-To: <20190527114914.GG15290@suse.cz>

On Mon, May 27, 2019 at 01:49:14PM +0200, David Sterba wrote:
> On Mon, May 27, 2019 at 05:17:19PM +0800, kernel test robot wrote:
> > Greeting,
> > 
> > FYI, we noticed a -13.2% regression of aim7.jobs-per-min due to commit:
> 
> That's interesting and worth an investigation. This should not happen,
> the code is almost the same, moved from one function to another and the
> call is direct. I'd suspect some low-level causes like cache effects or
> branching, the perf-stats.i.* show some differences.
> 
> Other stats say (slabinfo.*extent_buffer) that there was less work over
> the period. The slab object counter says that the object reuse was
> higher in the bad case.
> 
> And there are many stats that show two digit difference, I'm trying to
> make some sense of that, eg. if memory placement on NUMA nodes can
> affect the speed of checksumming (changed by the patch)
> 
> So I wonder how reliable the test is and if it really does the same
> thing in both cases or if there's some subtle change in the patch that
> we've missed.

Hi,

The test is unstable, we can't reproduce the issue. It's probably a false
positive, sorry for the inconvenience.

Best Regards,
Rong Chen

WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <rong.a.chen@intel.com>
To: lkp@lists.01.org
Subject: Re: [btrfs] 2996e1f8bc: aim7.jobs-per-min -13.2% regression
Date: Thu, 30 May 2019 21:32:15 +0800	[thread overview]
Message-ID: <20190530133215.GC22325@shao2-debian> (raw)
In-Reply-To: <20190527114914.GG15290@suse.cz>

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

On Mon, May 27, 2019 at 01:49:14PM +0200, David Sterba wrote:
> On Mon, May 27, 2019 at 05:17:19PM +0800, kernel test robot wrote:
> > Greeting,
> > 
> > FYI, we noticed a -13.2% regression of aim7.jobs-per-min due to commit:
> 
> That's interesting and worth an investigation. This should not happen,
> the code is almost the same, moved from one function to another and the
> call is direct. I'd suspect some low-level causes like cache effects or
> branching, the perf-stats.i.* show some differences.
> 
> Other stats say (slabinfo.*extent_buffer) that there was less work over
> the period. The slab object counter says that the object reuse was
> higher in the bad case.
> 
> And there are many stats that show two digit difference, I'm trying to
> make some sense of that, eg. if memory placement on NUMA nodes can
> affect the speed of checksumming (changed by the patch)
> 
> So I wonder how reliable the test is and if it really does the same
> thing in both cases or if there's some subtle change in the patch that
> we've missed.

Hi,

The test is unstable, we can't reproduce the issue. It's probably a false
positive, sorry for the inconvenience.

Best Regards,
Rong Chen

  reply	other threads:[~2019-05-30 13:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27  9:17 [btrfs] 2996e1f8bc: aim7.jobs-per-min -13.2% regression kernel test robot
2019-05-27  9:17 ` kernel test robot
2019-05-27 11:49 ` David Sterba
2019-05-27 11:49   ` David Sterba
2019-05-30 13:32   ` kernel test robot [this message]
2019-05-30 13:32     ` kernel test robot

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=20190530133215.GC22325@shao2-debian \
    --to=rong.a.chen@intel.com \
    --cc=dsterba@suse.cz \
    --cc=jthumshirn@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=nborisov@suse.com \
    --cc=torvalds@linux-foundation.org \
    --cc=wqu@suse.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.