public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Rik van Riel <riel@redhat.com>
Cc: Aaron Lu <aaron.lu@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@01.org, jhladky@redhat.com
Subject: Re: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local
Date: Tue, 29 Jul 2014 10:17:12 +0200	[thread overview]
Message-ID: <20140729081712.GS20603@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <20140729023940.37b6aebc@annuminas.surriel.com>

On Tue, Jul 29, 2014 at 02:39:40AM -0400, Rik van Riel wrote:
> Subject: sched,numa: prevent task moves with marginal benefit
> 
> Commit a43455a1d57 makes task_numa_migrate() always check the
> preferred node for task placement. This is causing a performance
> regression with hackbench, as well as SPECjbb2005.
> 
> Tracing task_numa_compare() with a single instance of SPECjbb2005
> on a 4 node system, I have seen several thread swaps with tiny
> improvements. 
> 
> It appears that the hysteresis code that was added to task_numa_compare
> is not doing what we needed it to do, and a simple threshold could be
> better.
> 
> Reported-by: Aaron Lu <aaron.lu@intel.com>
> Reported-by: Jirka Hladky <jhladky@redhat.com>
> Signed-off-by: Rik van Riel <riel@redhat.com>
> ---
>  kernel/sched/fair.c | 24 +++++++++++++++---------
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4f5e3c2..bedbc3e 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -924,10 +924,12 @@ static inline unsigned long group_faults_cpu(struct numa_group *group, int nid)
>  
>  /*
>   * These return the fraction of accesses done by a particular task, or
> - * task group, on a particular numa node.  The group weight is given a
> - * larger multiplier, in order to group tasks together that are almost
> - * evenly spread out between numa nodes.
> + * task group, on a particular numa node.  The NUMA move threshold
> + * prevents task moves with marginal improvement, and is set to 5%.
>   */
> +#define NUMA_SCALE 1000
> +#define NUMA_MOVE_THRESH 50

Please make that 1024, there's no reason not to use power of two here.
This base 10 factor thing annoyed me no end already, its time for it to
die.

  reply	other threads:[~2014-07-29  8:17 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53d70ee6.JsUEmW5dWsv8dev+%fengguang.wu@intel.com>
2014-07-29  5:24 ` [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local Aaron Lu
2014-07-29  6:39   ` Rik van Riel
2014-07-29  8:17     ` Peter Zijlstra [this message]
2014-07-29 20:04       ` Rik van Riel
2014-07-30  2:14         ` Aaron Lu
2014-07-30 14:25           ` Rik van Riel
2014-07-31  5:04             ` Aaron Lu
2014-07-31  6:22               ` Rik van Riel
2014-07-31  6:53                 ` Aaron Lu
2014-07-31  6:42               ` Rik van Riel
2014-08-05 21:43               ` Rik van Riel
2014-07-31  8:33           ` Peter Zijlstra
2014-07-31  8:56             ` Aaron Lu
2014-07-31 10:42     ` Peter Zijlstra
2014-07-31 15:57       ` Peter Zijlstra
2014-07-31 16:16         ` Jirka Hladky
2014-07-31 16:27           ` Peter Zijlstra
2014-07-31 16:39             ` Jirka Hladky
2014-07-31 17:37               ` Peter Zijlstra
2014-08-01 15:02                 ` Peter Zijlstra
2014-08-01 20:46           ` Davidlohr Bueso
2014-08-01 20:48             ` Davidlohr Bueso
2014-08-01 21:30             ` Jirka Hladky
2014-08-02  4:17               ` Rik van Riel
2014-08-02  5:28                 ` Jirka Hladky
2014-08-02  4:26               ` Peter Zijlstra
2014-08-01  0:18       ` Davidlohr Bueso
2014-08-01  2:03       ` Aaron Lu
2014-08-01  4:03         ` Davidlohr Bueso
2014-08-01  7:29           ` Peter Zijlstra
2014-08-01  7:29         ` Peter Zijlstra
2014-07-31 23:58           ` Yuyang Du
2014-08-01  8:14           ` Fengguang Wu

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=20140729081712.GS20603@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=aaron.lu@intel.com \
    --cc=jhladky@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --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