From: Jirka Hladky <jhladky@redhat.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Phil Auld <pauld@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
Valentin Schneider <valentin.schneider@arm.com>,
Hillf Danton <hdanton@sina.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/13] Reconcile NUMA balancing decisions with the load balancer v6
Date: Thu, 12 Mar 2020 23:24:29 +0100 [thread overview]
Message-ID: <CAE4VaGCfDpu0EuvHNHwDGbR-HNBSAHY=yu3DJ33drKgymMTTOw@mail.gmail.com> (raw)
In-Reply-To: <20200312214736.GA3818@techsingularity.net>
> I'll continue thinking about it but whatever chance there is of
> improving it while keeping CPU balancing, NUMA balancing and wake affine
> consistent with each other, I think there is no chance with the
> inconsistent logic used in the vanilla code :(
Thank you, Mel!
On Thu, Mar 12, 2020 at 10:47 PM Mel Gorman <mgorman@techsingularity.net> wrote:
>
> On Thu, Mar 12, 2020 at 05:54:29PM +0100, Jirka Hladky wrote:
> > >
> > > find it unlikely that is common because who acquires such a large machine
> > > and then uses a tiny percentage of it.
> >
> >
> > I generally agree, but I also want to make a point that AMD made these
> > large systems much more affordable with their EPYC CPUs. The 8 NUMA node
> > server we are using costs under $8k.
> >
> >
> >
> > > This is somewhat of a dilemma. Without the series, the load balancer and
> > > NUMA balancer use very different criteria on what should happen and
> > > results are not stable.
> >
> >
> > Unfortunately, I see instabilities also for the series. This is again for
> > the sp_C test with 8 threads executed on dual-socket AMD 7351 (EPYC Naples)
> > server with 8 NUMA nodes. With the series applied, the runtime varies from
> > 86 to 165 seconds! Could we do something about it? The runtime of 86
> > seconds would be acceptable. If we could stabilize this case and get
> > consistent runtime around 80 seconds, the problem would be gone.
> >
> > Do you experience the similar instability of results on your HW for sp_C
> > with low thread counts?
> >
>
> I saw something similar but observed that it depended on whether the
> worker tasks got spread wide or not which partially came down to luck.
> The question is if it's possible to pick a point where we spread wide
> and can recover quickly enough when tasks need to remain close without
> knowledge of the future. Putting a balancing limit on tasks that
> recently woke would be one option but that could also cause persistent
> improper balancing for tasks that wake frequently.
>
> > Runtime with this series applied:
> > $ grep "Time in seconds" *log
> > sp.C.x.defaultRun.008threads.loop01.log: Time in seconds =
> > 125.73
> > sp.C.x.defaultRun.008threads.loop02.log: Time in seconds =
> > 87.54
> > sp.C.x.defaultRun.008threads.loop03.log: Time in seconds =
> > 86.93
> > sp.C.x.defaultRun.008threads.loop04.log: Time in seconds =
> > 165.98
> > sp.C.x.defaultRun.008threads.loop05.log: Time in seconds =
> > 114.78
> >
> > For comparison, here are vanilla kernel results:
> > $ grep "Time in seconds" *log
> > sp.C.x.defaultRun.008threads.loop01.log: Time in seconds =
> > 59.83
> > sp.C.x.defaultRun.008threads.loop02.log: Time in seconds =
> > 67.72
> > sp.C.x.defaultRun.008threads.loop03.log: Time in seconds =
> > 63.62
> > sp.C.x.defaultRun.008threads.loop04.log: Time in seconds =
> > 55.01
> > sp.C.x.defaultRun.008threads.loop05.log: Time in seconds =
> > 65.20
> >
> >
> >
> > > In *general*, I found that the series won a lot more than it lost across
> > > a spread of workloads and machines but unfortunately it's also an area
> > > where counter-examples can be found.
> >
> >
> > OK, fair enough. I understand that there will always be trade-offs when
> > making changes to scheduler like this. And I agree that cases with higher
> > system load (where is series is helpful) outweigh the performance drops for
> > low threads counts. I was hoping that it would be possible to improve the
> > small threads results while keeping the gains for other scenarios:-) But
> > let's be realistic - I would be happy to fix the extreme case mentioned
> > above. The other issues where performance drop is about 20% are OK with me
> > and are outweighed by the gains for different scenarios.
> >
>
> I'll continue thinking about it but whatever chance there is of
> improving it while keeping CPU balancing, NUMA balancing and wake affine
> consistent with each other, I think there is no chance with the
> inconsistent logic used in the vanilla code :(
>
> --
> Mel Gorman
> SUSE Labs
>
--
-Jirka
next prev parent reply other threads:[~2020-03-12 22:24 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 9:52 [PATCH 00/13] Reconcile NUMA balancing decisions with the load balancer v6 Mel Gorman
2020-02-24 9:52 ` [PATCH 01/13] sched/fair: Allow a per-CPU kthread waking a task to stack on the same CPU, to fix XFS performance regression Mel Gorman
2020-02-24 9:52 ` [PATCH 02/13] sched/numa: Trace when no candidate CPU was found on the preferred node Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Mel Gorman
2020-02-24 9:52 ` [PATCH 03/13] sched/numa: Distinguish between the different task_numa_migrate failure cases Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] sched/numa: Distinguish between the different task_numa_migrate() " tip-bot2 for Mel Gorman
2020-02-24 9:52 ` [PATCH 04/13] sched/fair: Reorder enqueue/dequeue_task_fair path Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Vincent Guittot
2020-02-24 9:52 ` [PATCH 05/13] sched/numa: Replace runnable_load_avg by load_avg Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Vincent Guittot
2020-02-24 9:52 ` [PATCH 06/13] sched/numa: Use similar logic to the load balancer for moving between domains with spare capacity Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Mel Gorman
2020-02-24 9:52 ` [PATCH 07/13] sched/pelt: Remove unused runnable load average Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Vincent Guittot
2020-02-24 9:52 ` [PATCH 08/13] sched/pelt: Add a new runnable average signal Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Vincent Guittot
2020-02-24 16:01 ` Valentin Schneider
2020-02-24 16:34 ` Mel Gorman
2020-02-25 8:23 ` Vincent Guittot
2020-02-24 9:52 ` [PATCH 09/13] sched/fair: Take into account runnable_avg to classify group Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Vincent Guittot
2020-02-24 9:52 ` [PATCH 10/13] sched/numa: Prefer using an idle cpu as a migration target instead of comparing tasks Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] sched/numa: Prefer using an idle CPU " tip-bot2 for Mel Gorman
2020-02-24 9:52 ` [PATCH 11/13] sched/numa: Find an alternative idle CPU if the CPU is part of an active NUMA balance Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Mel Gorman
2020-02-24 9:52 ` [PATCH 12/13] sched/numa: Bias swapping tasks based on their preferred node Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Mel Gorman
2020-02-24 9:52 ` [PATCH 13/13] sched/numa: Stop an exhastive search if a reasonable swap candidate or idle CPU is found Mel Gorman
2020-02-24 15:20 ` [tip: sched/core] " tip-bot2 for Mel Gorman
2020-02-24 15:16 ` [PATCH 00/13] Reconcile NUMA balancing decisions with the load balancer v6 Ingo Molnar
2020-02-25 11:59 ` Mel Gorman
2020-02-25 13:28 ` Vincent Guittot
2020-02-25 14:24 ` Mel Gorman
2020-02-25 14:53 ` Vincent Guittot
2020-02-27 9:09 ` Ingo Molnar
2020-03-09 19:12 ` Phil Auld
2020-03-09 20:36 ` Mel Gorman
2020-03-12 9:54 ` Mel Gorman
2020-03-12 12:17 ` Jirka Hladky
[not found] ` <CAE4VaGA4q4_qfC5qe3zaLRfiJhvMaSb2WADgOcQeTwmPvNat+A@mail.gmail.com>
2020-03-12 15:56 ` Mel Gorman
2020-03-12 17:06 ` Jirka Hladky
[not found] ` <CAE4VaGD8DUEi6JnKd8vrqUL_8HZXnNyHMoK2D+1-F5wo+5Z53Q@mail.gmail.com>
2020-03-12 21:47 ` Mel Gorman
2020-03-12 22:24 ` Jirka Hladky [this message]
2020-03-20 15:08 ` Jirka Hladky
[not found] ` <CAE4VaGC09OfU2zXeq2yp_N0zXMbTku5ETz0KEocGi-RSiKXv-w@mail.gmail.com>
2020-03-20 15:22 ` Mel Gorman
2020-03-20 15:33 ` Jirka Hladky
[not found] ` <CAE4VaGBGbTT8dqNyLWAwuiqL8E+3p1_SqP6XTTV71wNZMjc9Zg@mail.gmail.com>
2020-03-20 16:38 ` Mel Gorman
2020-03-20 17:21 ` Jirka Hladky
2020-05-07 15:24 ` Jirka Hladky
2020-05-07 15:54 ` Mel Gorman
2020-05-07 16:29 ` Jirka Hladky
2020-05-07 17:49 ` Phil Auld
[not found] ` <20200508034741.13036-1-hdanton@sina.com>
2020-05-18 14:52 ` Jirka Hladky
[not found] ` <20200519043154.10876-1-hdanton@sina.com>
2020-05-20 13:58 ` Jirka Hladky
2020-05-20 16:01 ` Jirka Hladky
2020-05-21 11:06 ` Mel Gorman
[not found] ` <20200521140931.15232-1-hdanton@sina.com>
2020-05-21 16:04 ` Mel Gorman
[not found] ` <20200522010950.3336-1-hdanton@sina.com>
2020-05-22 11:05 ` Mel Gorman
2020-05-08 9:22 ` Mel Gorman
2020-05-08 11:05 ` Jirka Hladky
[not found] ` <CAE4VaGC_v6On-YvqdTwAWu3Mq4ofiV0pLov-QpV+QHr_SJr+Rw@mail.gmail.com>
2020-05-13 14:57 ` Jirka Hladky
2020-05-13 15:30 ` Mel Gorman
2020-05-13 16:20 ` Jirka Hladky
2020-05-14 9:50 ` Mel Gorman
[not found] ` <CAE4VaGCGUFOAZ+YHDnmeJ95o4W0j04Yb7EWnf8a43caUQs_WuQ@mail.gmail.com>
2020-05-14 10:08 ` Mel Gorman
2020-05-14 10:22 ` Jirka Hladky
2020-05-14 11:50 ` Mel Gorman
2020-05-14 13:34 ` Jirka Hladky
2020-05-14 15:31 ` Peter Zijlstra
2020-05-15 8:47 ` Mel Gorman
2020-05-15 11:17 ` Peter Zijlstra
2020-05-15 13:03 ` Mel Gorman
2020-05-15 13:12 ` Peter Zijlstra
2020-05-15 13:28 ` Peter Zijlstra
2020-05-15 14:24 ` Peter Zijlstra
2020-05-21 10:38 ` Mel Gorman
2020-05-21 11:41 ` Peter Zijlstra
2020-05-22 13:28 ` Mel Gorman
2020-05-22 14:38 ` Peter Zijlstra
2020-05-15 11:28 ` Peter Zijlstra
2020-05-15 12:22 ` Mel Gorman
2020-05-15 12:51 ` Peter Zijlstra
2020-05-15 14:43 ` Jirka Hladky
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='CAE4VaGCfDpu0EuvHNHwDGbR-HNBSAHY=yu3DJ33drKgymMTTOw@mail.gmail.com' \
--to=jhladky@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=hdanton@sina.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.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 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).