From: Dennis Zhou <dennis@kernel.org>
To: lkp@lists.01.org
Subject: Re: [percpu] ace7e70901: aim9.sync_disk_rw.ops_per_sec -2.3% regression
Date: Tue, 11 May 2021 00:44:18 +0000 [thread overview]
Message-ID: <YJnTYicu2TaVqVmi@google.com> (raw)
In-Reply-To: <YJnRHhK+2AVTMOfh@carbon.DHCP.thefacebook.com>
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
On Mon, May 10, 2021 at 05:34:38PM -0700, Roman Gushchin wrote:
> On Fri, May 07, 2021 at 07:08:03PM +0000, Dennis Zhou wrote:
> > On Fri, May 07, 2021 at 10:52:22AM -0700, Roman Gushchin wrote:
> > > On Fri, May 07, 2021 at 11:06:06AM +0800, Oliver Sang wrote:
> > > > hi Roman,
> > > >
> > > > On Thu, May 06, 2021 at 12:54:59AM +0000, Roman Gushchin wrote:
> > > > > Ping
> > > >
> > > > sorry for late.
> > > >
> > > > the new patch makes the performance a little better but still has
> > > > 1.9% regression comparing to
> > > > f183324133 ("percpu: implement partial chunk depopulation")
> > >
> > > Hi Oliver!
> > >
> > > Thank you for testing it!
> > >
> > > Btw, can you, please, confirm that the regression is coming specifically
> > > from ace7e70901 ("percpu: use reclaim threshold instead of running for every page")?
> > > I do see *some* regression in my setup, but the data is very noisy, so I'm not sure
> > > I can confirm it.
> > >
> > > Thanks!
> >
> > Thanks Oliver and Roman. If this is the case, I'll drop the final patch
> > and just merge up to f183324133 ("percpu: implement partial chunk
> > depopulation") into for-next as this is v5.14 anyway.
>
> I doubt it's a good idea. I reran the test with some debug added and it looks
> like it doesn't trigger any depopulation at all. Everything else looked sane
> too.
>
Well that's awkward...
> Dropping a reasonable patch doing a good thing without any understandinding how
> it affects (or even can affect in theory) some benchmark sounds like a bad idea.
> We'll never learn this. It could be that the regression is caused my some
> tiny alignment difference or something like this, so any other change can
> trigger it too (I can be totally wrong here, but I don't have any better
> explanation either).
>
So I'm not 100% thrilled with the final patch anyway. Particularly the
lock dancing I'd rather figure something out a little cleaner. I'm going
to take some time later this week and sort it out. If I can't think of
anthing better I'll just reapply the final patch.
I've currently merged everything up into the last patch for-5.14. Should
at least give us some very preliminary testing.
> Btw, do we have any similar tests?
>
> Thanks!
Thanks,
Dennis
WARNING: multiple messages have this Message-ID (diff)
From: Dennis Zhou <dennis@kernel.org>
To: Roman Gushchin <guro@fb.com>
Cc: Oliver Sang <oliver.sang@intel.com>,
Pratik Sampat <psampat@linux.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
"lkp@lists.01.org" <lkp@lists.01.org>,
"lkp@intel.com" <lkp@intel.com>,
"ying.huang@intel.com" <ying.huang@intel.com>,
"feng.tang@intel.com" <feng.tang@intel.com>,
"zhengjun.xing@intel.com" <zhengjun.xing@intel.com>
Subject: Re: [percpu] ace7e70901: aim9.sync_disk_rw.ops_per_sec -2.3% regression
Date: Tue, 11 May 2021 00:44:18 +0000 [thread overview]
Message-ID: <YJnTYicu2TaVqVmi@google.com> (raw)
In-Reply-To: <YJnRHhK+2AVTMOfh@carbon.DHCP.thefacebook.com>
On Mon, May 10, 2021 at 05:34:38PM -0700, Roman Gushchin wrote:
> On Fri, May 07, 2021 at 07:08:03PM +0000, Dennis Zhou wrote:
> > On Fri, May 07, 2021 at 10:52:22AM -0700, Roman Gushchin wrote:
> > > On Fri, May 07, 2021 at 11:06:06AM +0800, Oliver Sang wrote:
> > > > hi Roman,
> > > >
> > > > On Thu, May 06, 2021 at 12:54:59AM +0000, Roman Gushchin wrote:
> > > > > Ping
> > > >
> > > > sorry for late.
> > > >
> > > > the new patch makes the performance a little better but still has
> > > > 1.9% regression comparing to
> > > > f183324133 ("percpu: implement partial chunk depopulation")
> > >
> > > Hi Oliver!
> > >
> > > Thank you for testing it!
> > >
> > > Btw, can you, please, confirm that the regression is coming specifically
> > > from ace7e70901 ("percpu: use reclaim threshold instead of running for every page")?
> > > I do see *some* regression in my setup, but the data is very noisy, so I'm not sure
> > > I can confirm it.
> > >
> > > Thanks!
> >
> > Thanks Oliver and Roman. If this is the case, I'll drop the final patch
> > and just merge up to f183324133 ("percpu: implement partial chunk
> > depopulation") into for-next as this is v5.14 anyway.
>
> I doubt it's a good idea. I reran the test with some debug added and it looks
> like it doesn't trigger any depopulation at all. Everything else looked sane
> too.
>
Well that's awkward...
> Dropping a reasonable patch doing a good thing without any understandinding how
> it affects (or even can affect in theory) some benchmark sounds like a bad idea.
> We'll never learn this. It could be that the regression is caused my some
> tiny alignment difference or something like this, so any other change can
> trigger it too (I can be totally wrong here, but I don't have any better
> explanation either).
>
So I'm not 100% thrilled with the final patch anyway. Particularly the
lock dancing I'd rather figure something out a little cleaner. I'm going
to take some time later this week and sort it out. If I can't think of
anthing better I'll just reapply the final patch.
I've currently merged everything up into the last patch for-5.14. Should
at least give us some very preliminary testing.
> Btw, do we have any similar tests?
>
> Thanks!
Thanks,
Dennis
next prev parent reply other threads:[~2021-05-11 0:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-27 7:34 [percpu] ace7e70901: aim9.sync_disk_rw.ops_per_sec -2.3% regression kernel test robot
2021-04-27 7:34 ` kernel test robot
2021-04-30 1:25 ` Roman Gushchin
2021-04-30 1:25 ` Roman Gushchin
2021-05-06 0:54 ` Roman Gushchin
2021-05-06 0:54 ` Roman Gushchin
2021-05-07 3:06 ` Oliver Sang
2021-05-07 3:06 ` Oliver Sang
2021-05-07 17:52 ` Roman Gushchin
2021-05-07 17:52 ` Roman Gushchin
2021-05-07 19:08 ` Dennis Zhou
2021-05-07 19:08 ` Dennis Zhou
2021-05-11 0:34 ` Roman Gushchin
2021-05-11 0:34 ` Roman Gushchin
2021-05-11 0:44 ` Dennis Zhou [this message]
2021-05-11 0:44 ` Dennis Zhou
2021-05-11 1:13 ` Roman Gushchin
2021-05-11 1:13 ` Roman Gushchin
2021-05-11 1:27 ` Dennis Zhou
2021-05-11 1:27 ` Dennis Zhou
2021-05-11 2:26 ` Oliver Sang
2021-05-11 2:26 ` Oliver Sang
2021-05-11 2:52 ` Dennis Zhou
2021-05-11 2:52 ` Dennis Zhou
2021-05-11 5:57 ` Oliver Sang
2021-05-11 5:57 ` Oliver Sang
2021-05-11 2:13 ` Oliver Sang
2021-05-11 2:13 ` Oliver Sang
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=YJnTYicu2TaVqVmi@google.com \
--to=dennis@kernel.org \
--cc=lkp@lists.01.org \
/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.