Messages in this thread Patch in this message | | | Date | Wed, 25 Jun 2014 01:25:00 -0400 | From | Rik van Riel <> | Subject | Re: [PATCH 9/7] sched,numa: remove task_h_load from task_numa_compare |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/25/2014 01:21 AM, Peter Zijlstra wrote: > On Wed, Jun 25, 2014 at 07:07:35AM +0200, Peter Zijlstra wrote: >> Shall I merge this into patch 3? > > Which gets me the below; which is has a wrong changelog. > > task_h_load() already computes the load as seen from the root > group. effective_load() just does a better (and more expensive) job > of computing the task movement implications of a move. > > So the total effect of this patch shouldn't be very big; regular > load balancing also only uses task_h_load(), see move_tasks(). > > Now, we don't run with preemption disabled, don't run as often, > etc.., so maybe we can indeed use the more expensive variant just > fine, but does it really matter?
In my testing, it appears to make a difference between workloads converging, and workloads sitting with one last thread stuck on another node that never gets moved...
> --- Subject: sched,numa: use effective_load to balance NUMA loads > From: Rik van Riel <riel@redhat.com> Date: Mon, 23 Jun 2014 > 11:46:14 -0400 > > When CONFIG_FAIR_GROUP_SCHED is enabled, the load that a task > places on a CPU is determined by the group the task is in. This is > conveniently calculated for us by effective_load(), which > task_numa_compare should use. > > The active groups on the source and destination CPU can be > different, so the calculation needs to be done separately for each > CPU. > > Cc: mgorman@suse.de Cc: mingo@kernel.org Cc: chegu_vinod@hp.com > Signed-off-by: Rik van Riel <riel@redhat.com> Signed-off-by: Peter > Zijlstra <peterz@infradead.org> Link: > http://lkml.kernel.org/r/1403538378-31571-3-git-send-email-riel@redhat.com > > - --- > kernel/sched/fair.c | 20 ++++++++++++++------ 1 file changed, 14 > insertions(+), 6 deletions(-) > > --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1151,6 > +1151,7 @@ static void task_numa_compare(struct tas struct rq > *src_rq = cpu_rq(env->src_cpu); struct rq *dst_rq = > cpu_rq(env->dst_cpu); struct task_struct *cur; + struct task_group > *tg; long src_load, dst_load; long load; long imp = (groupimp > 0) > ? groupimp : taskimp; @@ -1225,14 +1226,21 @@ static void > task_numa_compare(struct tas * In the overloaded case, try and keep > the load balanced. */ balance: - load = task_h_load(env->p); - > dst_load = env->dst_stats.load + load; - src_load = > env->src_stats.load - load; + src_load = env->src_stats.load; + > dst_load = env->dst_stats.load; + + /* Calculate the effect of > moving env->p from src to dst. */ + load = env->p->se.load.weight; > + tg = task_group(env->p); + src_load += effective_load(tg, > env->src_cpu, -load, -load); + dst_load += effective_load(tg, > env->dst_cpu, load, load); > > if (cur) { - load = task_h_load(cur); - dst_load -= load; - > src_load += load; + /* Cur moves in the opposite direction. */ + > load = cur->se.load.weight; + tg = task_group(cur); + src_load += > effective_load(tg, env->src_cpu, load, load); + dst_load += > effective_load(tg, env->dst_cpu, -load, -load); } > > if (load_too_imbalanced(src_load, dst_load, env)) > >
- -- All rights reversed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTql0sAAoJEM553pKExN6DUEsH/2a+gHC79Ywih7PmbvS8q3JF AW5tOHrwNK4nU+12hpOuPgF7rK2SqDEMievxGI9oNf2zNx8JsKUFQes5WVHeN4JZ dOeF1iCZV1KOTxsTOgnfR+dmbZAw3dRRVCysQae4Xm1PlXPgUef0HZSJ4rgdxARb HqkKokfxDframBBnkeu8QMNzvygt8oZsXYmT2fjJ8lhXuaSIgIl5GWPb4hK5ntfs 0NjE3xPKV5nJxD6ut0gGSrWAaNTg3k7IAhAJf72pzs0gnIHqa0M4AV0NIPgS5QUd qcCLYSVisdoOiMlHxqxESNhBYTnfmpJdcQ6Cj3CWkaKdiFCGEyu0391AY3Or+zg= =udqV -----END PGP SIGNATURE-----
| |