linux-kernel - Re: [PATCH 7/7] sched,numa: change scan period code to match intent

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: <20140625101954.GY10819@suse.de>
Date:	Wed, 25 Jun 2014 11:19:54 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	riel@...hat.com
Cc:	linux-kernel@...r.kernel.org, chegu_vinod@...com,
	peterz@...radead.com, mingo@...nel.org
Subject: Re: [PATCH 7/7] sched,numa: change scan period code to match intent

On Mon, Jun 23, 2014 at 11:41:35AM -0400, riel@...hat.com wrote:
> From: Rik van Riel <riel@...hat.com>
> 
> Reading through the scan period code and comment, it appears the
> intent was to slow down NUMA scanning when a majority of accesses
> are on the local node, specifically a local:remote ratio of 3:1.
> 
> However, the code actually tests local / (local + remote), and
> the actual cut-off point was around 30% local accesses, well before
> a task has actually converged on a node.
> 
> Changing the threshold to 7 means scanning slows down when a task
> has around 70% of its accesses local, which appears to match the
> intent of the code more closely.
> 
> Cc: Mel Gorman <mgorman@...e.de>
> Signed-off-by: Rik van Riel <riel@...hat.com>

The threshold is indeed very low and was selected to favour slowing
down scanning over convergence time. This was with the intent that we
should never perform worse than disabling NUMA balancing -- an aim that
has mixed results with recent Java-based workloads. With slower scanning,
we converge eventually so for long-lived workloads we're ok.  On the other
hand if scan rate is continually high and we're not converging then system
overhead stays consistently high. I considered the slow convergence to be
the lesser of two possible evils.

At the time of writing there were basic workloads that were only seeing about
20-30% locality hence that threshold. Since then, things have changed that
may affect that decision -- pseudo-interleaving was introduced for example.

I've no problem with the patch because it could do with re-evaluation in
the context of the other recent changes so

Acked-by: Mel Gorman <mgorman@...e.de>

Watch for consistently high scanning activity or high system CPU usage and
if either is reported it's worth looking to see if that 70% threshold is
ever been reached.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/