linux-kernel - Re: [PATCH 18/52] mm/numa: Migrate on reference policy

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]

Date:	Mon, 3 Dec 2012 15:44:58 +0000
From:	Mel Gorman <mgorman@...e.de>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>,
	Alex Shi <lkml.alex@...il.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Aneesh Kumar <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: [PATCH 18/52] mm/numa: Migrate on reference policy

On Sun, Dec 02, 2012 at 07:43:10PM +0100, Ingo Molnar wrote:
> From: Mel Gorman <mgorman@...e.de>
> 
> This is the simplest possible policy that still does something
> of note. When a pte_numa is faulted, it is moved immediately.
> Any replacement policy must at least do better than this and in
> all likelihood this policy regresses normal workloads.
> 
> Signed-off-by: Mel Gorman <mgorman@...e.de>
> Acked-by: Rik van Riel <riel@...hat.com>
> Cc: Johannes Weiner <hannes@...xchg.org>
> Cc: Hugh Dickins <hughd@...gle.com>
> Cc: Paul Turner <pjt@...gle.com>
> Cc: Lee Schermerhorn <Lee.Schermerhorn@...com>
> Cc: Alex Shi <lkml.alex@...il.com>
> Cc: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> Cc: Aneesh Kumar <aneesh.kumar@...ux.vnet.ibm.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Cc: Andrea Arcangeli <aarcange@...hat.com>
> Signed-off-by: Ingo Molnar <mingo@...nel.org>

It is worth noting that at this point in your combined tree that this
policy and patch does not and cannot do anything. It has none of the
faulting machinery, pte scanning, two-stage filter etc that are necessary
for it to work. So for example, you can not take this point of your tree,
compare it with balancenuma and get a meaningful comparison.

So while superfically this patch looks like a useful bisection point, it
isn't. A plain rebase on top of balancenuma would have given us a comparison
between "do nothing", "do the bare minimum to be useful (balancenuma)" and
"do something complex (numacore)" even *if* you decided to revert parts
of balancenuma during your rebase. For example, you might have decided
to force the removal of migrate rate-limiting even though I stand by it
being a valid decision to mitigate worst-case behaviour. The key is that
it would have been possible to bisect parts of numacore to help identify
the source of any regressions.

This restructure is an all or nothing approach. It does not look like it's
possible to do a comparison between "do nothing", "do the bare minimum
(balancenuma)" and "do something complex (numacore)". It would also be
impossible to do any sort of rebase of autonuma policies on top as was
the case with balancenuma.

FWIW, I pulled tip again this morning and rebased tip/numa/base to
3.7-rc7 and queued the result. I had pulled tip/master but it didn't
boot.

-- 
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/