linux-kernel - Re: [PATCH 08/19] mm: numa: Create basic numa page hinting infrastructure

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: <20121113102120.GD21522@gmail.com>
Date:	Tue, 13 Nov 2012 11:21:20 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 08/19] mm: numa: Create basic numa page hinting
 infrastructure

* Mel Gorman <mgorman@...e.de> wrote:

> Note: This patch started as "mm/mpol: Create special PROT_NONE
> 	infrastructure" and preserves the basic idea but steals *very*
> 	heavily from "autonuma: numa hinting page faults entry points" for
> 	the actual fault handlers without the migration parts.	The end
> 	result is barely recognisable as either patch so all Signed-off
> 	and Reviewed-bys are dropped. If Peter, Ingo and Andrea are ok with
> 	this version, I will re-add the signed-offs-by to reflect the history.

Most of the changes you had to do here relates to the earlier 
decision to turn it all the NUMA protection fault demultiplexing 
and setup code into a per arch facility.

On one hand I'm 100% fine with making the decision to *use* the 
new NUMA code per arch and explicitly opt-in - we already have 
such a Kconfig switch in our tree already. The decision whether 
to use any of this for an architecture must be considered and 
tested carefully.

But given that most architectures will be just fine reusing the 
already existing generic PROT_NONE machinery, the far better 
approach is to do what we've been doing in generic kernel code 
for the last 10 years: offer a default generic version, and then 
to offer per arch hooks on a strict as-needed basis, if they 
want or need to do something weird ...

So why fork away this logic into per arch code so early and 
without explicit justification? It creates duplication artifacts 
all around and makes porting to a new 'sane' architecture 
harder.

Also, if there *are* per architecture concerns then I'd very 
much like to see that argued very explicitly, on a per arch 
basis, as it occurs, not obscured through thick "just in case" 
layers of abstraction ...

Thanks,

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