public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: linux-kernel@vger.kernel.org, mgorman@suse.de,
	peterz@infradead.org, jhladky@redhat.com
Subject: Re: [PATCH] numa,sched: only consider less busy nodes as numa balancing destination
Date: Tue, 26 May 2015 16:29:27 -0400	[thread overview]
Message-ID: <5564D7A7.6000403@redhat.com> (raw)
In-Reply-To: <20150506114128.0c846a37@cuia.bos.redhat.com>

On 05/06/2015 11:41 AM, Rik van Riel wrote:
> On Wed, 06 May 2015 13:35:30 +0300
> Artem Bityutskiy <dedekind1@gmail.com> wrote:
> 
>> we observe a tremendous regression between kernel version 3.16 and 3.17
>> (and up), and I've bisected it to this commit:
>>
>> a43455a sched/numa: Ensure task_numa_migrate() checks the preferred node
> 
> Artem, Jirka, does this patch fix (or at least improve) the issues you
> have been seeing?  Does it introduce any new regressions?
> 
> Peter, Mel, I think it may be time to stop waiting for the impedance
> mismatch between the load balancer and NUMA balancing to be resolved,
> and try to just avoid the issue in the NUMA balancing code...

Peter, I got some more test results in.  This patch can supercede
095bebf61a46 ("sched/numa: Do not move past the balance point if
unbalanced"), which can be reverted.

With this patch, a workload that has one (misplaced) thread running,
and nothing else on the system, is able to move to the node where
its memory is, which is something that 095bebf61a46 prevented.

It also fixes the single instance SpecJBB2005 spreading issue, which
benefited some (but not completely) from 095bebf61a46 in the past.

Peter, what would you like me to do to get this patch into your tree,
and 095bebf61a46 reverted? :)

-- 
All rights reversed

      parent reply	other threads:[~2015-05-26 20:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06 10:35 autoNUMA web workload regression Artem Bityutskiy
2015-05-06 10:37 ` Bityutskiy, Artem
2015-05-06 14:40 ` Rik van Riel
2015-05-06 15:41 ` [PATCH] numa,sched: only consider less busy nodes as numa balancing destination Rik van Riel
2015-05-06 17:00   ` Peter Zijlstra
2015-05-06 17:06     ` Rik van Riel
2015-05-07 13:29   ` Artem Bityutskiy
2015-05-08 13:13   ` Artem Bityutskiy
2015-05-08 20:03     ` Rik van Riel
2015-05-08 22:52       ` Rik van Riel
2015-05-11 11:11       ` Artem Bityutskiy
2015-05-11 14:20         ` Rik van Riel
2015-05-12 13:50       ` Artem Bityutskiy
2015-05-12 15:45         ` Rik van Riel
2015-05-13  6:29           ` Peter Zijlstra
2015-05-13  6:31             ` Peter Zijlstra
2015-05-13 10:59             ` Artem Bityutskiy
2015-05-13 13:51             ` Rik van Riel
2015-05-11 12:44   ` Jirka Hladky
2015-05-11 14:44     ` Rik van Riel
2015-05-26 20:29   ` Rik van Riel [this message]

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=5564D7A7.6000403@redhat.com \
    --to=riel@redhat.com \
    --cc=dedekind1@gmail.com \
    --cc=jhladky@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.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