linux-kernel - Re: [PATCH v2 2/4] sched:Consider imbalance_pct when comparing loads in numa_has

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150622162958.GB32412@linux.vnet.ibm.com>
Date:	Mon, 22 Jun 2015 21:59:58 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH v2 2/4] sched:Consider imbalance_pct when comparing loads
 in numa_has_capacity

* Rik van Riel <riel@...hat.com> [2015-06-16 10:39:13]:

> On 06/16/2015 07:56 AM, Srikar Dronamraju wrote:
> > This is consistent with all other load balancing instances where we
> > absorb unfairness upto env->imbalance_pct. Absorbing unfairness upto
> > env->imbalance_pct allows to pull and retain task to their preferred
> > nodes.
> >
> > Signed-off-by: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
>
> How does this work with other workloads, eg.
> single instance SPECjbb2005, or two SPECjbb2005
> instances on a four node system?
>
> Is the load still balanced evenly between nodes
> with this patch?
>

Yes, I have looked at mpstat logs while running SPECjbb2005 for 1JVMper
System, 2 JVMs per System and 4 JVMs per System and observed that the
load spreading was similar with and without this patch.

Also I have visualized using htop when running 0.5X (i.e 48 threads on
96 cpu system) cpu stress workloads to see that the spread is similar
before and after the patch.

Please let me know if there are any better ways to observe the
spread. In a slightly loaded or less loaded system, the chance of
migrating threads to their home node by way of calling migrate_task_to
and migrate_swap might be curtailed without this patch. i.e 2 process
each having N/2 threads may converge slower without this change.

--
Thanks and Regards
Srikar Dronamraju

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/