Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754752Ab2KMKV0 (ORCPT ); Tue, 13 Nov 2012 05:21:26 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:47602 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753338Ab2KMKVZ (ORCPT ); Tue, 13 Nov 2012 05:21:25 -0500 Date: Tue, 13 Nov 2012 11:21:20 +0100 From: Ingo Molnar To: Mel Gorman Cc: Peter Zijlstra , Andrea Arcangeli , Rik van Riel , Johannes Weiner , Hugh Dickins , Thomas Gleixner , Linus Torvalds , Andrew Morton , Linux-MM , LKML Subject: Re: [PATCH 08/19] mm: numa: Create basic numa page hinting infrastructure Message-ID: <20121113102120.GD21522@gmail.com> References: <1352193295-26815-1-git-send-email-mgorman@suse.de> <1352193295-26815-9-git-send-email-mgorman@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1352193295-26815-9-git-send-email-mgorman@suse.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1995 Lines: 46 * Mel Gorman 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/