From: Peter Zijlstra <peterz@infradead.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com
Subject: Re: [PATCH] sched,numa: do not move past the balance point if unbalanced
Date: Thu, 15 Jan 2015 11:45:17 +0100 [thread overview]
Message-ID: <20150115104517.GR23965@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20150112163039.7eb9a9e0@annuminas.surriel.com>
On Mon, Jan 12, 2015 at 04:30:39PM -0500, Rik van Riel wrote:
> There is a subtle interaction between the logic introduced in commit
> e63da03639cc9e6e83b62e7ef8ffdbb92421416a, the way the load balancer
e63da03639cc ("sched/numa: Allow task switch if load imbalance improves")
I have the below in my .gitconfig to easily create them things:
[core]
abbrev = 12
[alias]
one = show -s --pretty='format:%h (\"%s\")'
> counts the load on each NUMA node, and the way NUMA hinting faults are
> done.
>
> Specifically, the load balancer only counts currently running tasks
> in the load, while NUMA hinting faults may cause tasks to stop, if
> the page is locked by another task.
>
> This could cause all of the threads of a large single instance workload,
> like SPECjbb2005, to migrate to the same NUMA node. This was possible
> because occasionally they all fault on the same few pages, and only one
> of the threads remains runnable. That thread can move to the process's
> preferred NUMA node without making the imbalance worse, because nothing
> else is running at that time.
>
> The fix is to check the direction of the net moving of load, and to
> refuse a NUMA move if it would cause the system to move past the point
> of balance. In an unbalanced state, only moves that bring us closer
> to the balance point are allowed.
Did you also test with whatever load needed the previous thing? Its far
too easy to fix one and break the other in my experience ;-)
> orig_src_load = env->src_stats.load;
> - orig_dst_load = env->dst_stats.load;
>
> - if (orig_dst_load < orig_src_load)
> - swap(orig_dst_load, orig_src_load);
> -
> - old_imb = orig_dst_load * src_capacity * 100 -
> - orig_src_load * dst_capacity * env->imbalance_pct;
> + /*
> + * In a task swap, there will be one load moving from src to dst,
> + * and another moving back. This is the net sum of both moves.
> + * Allow the move if it brings the system closer to a balanced
> + * situation, without crossing over the balance point.
> + */
This comment seems to 'forget' about the !swap moves?
> + moved_load = orig_src_load - src_load;
>
> - /* Would this change make things worse? */
> - return (imb > old_imb);
> + if (moved_load > 0)
> + /* Moving src -> dst. Did we overshoot balance? */
> + return src_load < dst_load;
So here we inhibit movement when the src cpu gained (moved_load > 0) and
src was smaller than dst.
However there is no check the new src value is in fact bigger than dst;
src could have gained and still be smaller. And afaict that's a valid
move, even under the proposed semantics, right?
> + else
> + /* Moving dst -> src. Did we overshoot balance? */
> + return dst_load < src_load;
And vs.
> }
One should use capacity muck when comparing load between CPUs.
In any case, brain hurt.
next prev parent reply other threads:[~2015-01-15 10:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-12 21:30 [PATCH] sched,numa: do not move past the balance point if unbalanced Rik van Riel
2015-01-15 10:45 ` Peter Zijlstra [this message]
2015-01-15 18:21 ` Rik van Riel
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=20150115104517.GR23965@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=riel@redhat.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