From: Linus Torvalds <torvalds@linux-foundation.org>
To: kernel test robot <rong.a.chen@intel.com>
Cc: Jann Horn <jannh@google.com>, LKML <linux-kernel@vger.kernel.org>,
lkp@lists.01.org
Subject: Re: [mm] fd4d9c7d0c: stress-ng.switch.ops_per_sec -30.5% regression
Date: Thu, 26 Mar 2020 09:57:45 -0700 [thread overview]
Message-ID: <CAHk-=wi2c3UcK4fjUR2nM-7iUOAyQijq9ETfQHaN0WwFh2Bm9A@mail.gmail.com> (raw)
In-Reply-To: <20200326055723.GL11705@shao2-debian>
On Wed, Mar 25, 2020 at 10:57 PM kernel test robot
<rong.a.chen@intel.com> wrote:
>
> FYI, we noticed a -30.5% regression of stress-ng.switch.ops_per_sec due to commit:
>
> commit: fd4d9c7d0c71866ec0c2825189ebd2ce35bd95b8 ("mm: slub: add missing TID bump in kmem_cache_alloc_bulk()")
This looks odd.
I would not expect the update of c->tid to have that noticeable an
impact, even on a big machine that might be close to some scaling
limit.
It doesn't add any expensive atomic ops, and while it _could_ make a
percpu cacheline dirty, I think that cacheline should already be dirty
anyway under any load where this is noticeable. Plus this should be a
relatively cold path anyway.
So mind humoring me, and double-check that regression?
Of course, it might be another "just magic cache placement" detail
where code moved enough to make a difference.
Or maybe it really ends up causing new tid mismatches and we end up
failing the fast path in slub as a result. But looking at the stats
that changed in your message doesn't make me go "yeah, that looks like
a slub difference".
So before we look more at this, I'd like to make sure that the
regression is actually real, and not noise.
Please?
Linus
next prev parent reply other threads:[~2020-03-26 16:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 5:57 [mm] fd4d9c7d0c: stress-ng.switch.ops_per_sec -30.5% regression kernel test robot
2020-03-26 16:57 ` Linus Torvalds [this message]
2020-03-27 8:46 ` Rong Chen
2020-03-30 1:12 ` [LKP] " Feng Tang
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='CAHk-=wi2c3UcK4fjUR2nM-7iUOAyQijq9ETfQHaN0WwFh2Bm9A@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@lists.01.org \
--cc=rong.a.chen@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).