Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <CAE4VaGBeTy-du_tThkr3w-r2KbYW8m+sRcpDPn9sYeENUy_x4g@mail.gmail.com>
References: <CAE4VaGC+FcE4cTUwzTLuCRd8rnd-=MhSZHfjKstiRTKcYq-39g@mail.gmail.com>
 <20180907125649.GA3995@linux.vnet.ibm.com> <20180907131923.GB24106@hirez.programming.kicks-ass.net>
 <20180907134420.GD3995@linux.vnet.ibm.com> <20180907135235.GE24106@hirez.programming.kicks-ass.net>
 <CAE4VaGBeTy-du_tThkr3w-r2KbYW8m+sRcpDPn9sYeENUy_x4g@mail.gmail.com>
From:   Jirka Hladky <jhladky@redhat.com>
Date:   Fri, 14 Sep 2018 16:50:20 +0200
Message-ID: <CAE4VaGDoxOQEhPYtVzEkNdrnFQ=Lnjj2is71ZYUBn_csUreoNA@mail.gmail.com>
Subject: Re: [SCHEDULER] Performance drop in 4.19 compared to 4.18 kernel
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        "Jakub Ra??ek" <jracek@redhat.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "kkolakow@redhat.com" <kkolakow@redhat.com>,
        Ingo Molnar <mingo@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Peter and Srikar,

> I have bounced the 5 patches to you, (one of the 6 has not been applied by
> Peter) so I have skipped that.
> They can also be fetched from
> http://lore.kernel.org/lkml/1533276841-16341-1-git-send-email-srikar@linux.vnet.ibm.com

I'm sorry for the delay, we have finally the results for the above
kernel. The performance results look good compared to 4.19 vanilla and
are about the same as Mel's sched-numa-fast-crossnode-v1r12 patch set
for 4.18:

Compared to kernel-4.19.0-0.rc1.1

  * Improvement upto 20% for SPECjbb2005, SPECjvm2008 benchmarks
  * Improvement upto 50% for stream benchmark
  * Improvement upto 100% for the NAS benchmark (sp_C subtest, 8
threads on 4 NUMA system with 4x E5-4610 v2 @ 2.30GHz, 64 cores in
total)

When I compare it against Mel's patchset
(git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git
sched-numa-fast-crossnode-v1r12)

  * Mel's kernel is about 15% faster for stream benchmarks
  * The other benchmarks show very similar results with both kernels

Mel's patchset eliminates NUMA migration rate limits, this is
presumbly the reason for the good stream results.

Do you have any update when the current patchset could be merged into
the upstream kernel?

Thanks a lot!
Jirka

On Sun, Sep 9, 2018 at 4:03 PM, Jirka Hladky <jhladky@redhat.com> wrote:
>
> Hi Peter and Srikar,
>
> thanks a lot for the information and for the patches to test!
>
> > I have bounced the 5 patches to you, (one of the 6 has not been applied by
> > Peter) so I have skipped that.
> > They can also be fetched from
> > http://lore.kernel.org/lkml/1533276841-16341-1-git-send-email-srikar@linux.vnet.ibm.com
>
> We have started the benchmarks, I will report the results on Monday.
>
> > I generally run specjbb2005 (single and multi instance).
> We also run a single and multi-instance specjbb2005 test.
>
> > I have tried running NAS but I couldn't set it up properly.
> We run the OMP variant and we control the number of threads with the
> OMP_NUM_THREADS env variable. The setup is quite simple:
>
> cd NPB_sources/config/
> mv suite_x86_64.def suite.def
> cd ..
> make suite
>
> FYI - starting from 4.17 kernel there is a significant performance
> drop compared to 4.16 kernel. Mel has come up with a
> sched-numa-fast-crossnode-v1r12 patch series
> git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git which we have
> tested extensively and with it, the benchmarks results are back at
> 4.16 level. As I understand it, Mel's patch series depends on your
> patch series and can be only merged when your patches are completed.
>
> Thanks!
> Jirka
>
>
> On Fri, Sep 7, 2018 at 3:52 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Fri, Sep 07, 2018 at 07:14:20PM +0530, Srikar Dronamraju wrote:
> > > * Peter Zijlstra <peterz@infradead.org> [2018-09-07 15:19:23]:
> > >
> > > > On Fri, Sep 07, 2018 at 06:26:49PM +0530, Srikar Dronamraju wrote:
> > > >
> > > > > Can you please pick
> > > > >
> > > > >
> > > > > 1. 69bb3230297e881c797bbc4b3dbf73514078bc9d sched/numa: Stop multiple tasks
> > > > > from moving to the cpu at the same time
> > > > > 2. dc62cfdac5e5b7a61cd8a2bd4190e80b9bb408fc sched/numa: Avoid task migration
> > > > > for small numa improvement
> > > > > 3. 76e18a67cdd9e3609716c8a074c03168734736f9 sched/numa: Pass destination cpu as
> > > > > a parameter to migrate_task_rq
> > > > > 4.  489c19b440ebdbabffe530b9a41389d0a8b315d9 sched/numa: Reset scan rate
> > > > > whenever task moves across nodes
> > > > > 5.  b7e9ae1ae3825f35cd0f38f1f0c8e91ea145bc30 sched/numa: Limit the
> > > > > conditions where scan period is reset
> > > > >
> > > > > from https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/kernel/sched
> > > >
> > > > That is not a stable tree; the whole thing is re-generated from my quilt
> > > > set every time I feel like it.
> > > >
> > > > It is likely those commit ids will no longer exist in a few hours.
> > > >
> > >
> > > Okay, I will forward the relevant mails to Jirka.
> >
> > Or he can click on that link and find new IDs :-)