* Mel Gorman <mgorman@xxxxxxx> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>