On Tue, Nov 13, 2012 at 11:25:55AM +0100, Ingo Molnar wrote: > > * Mel Gorman <mgor...@suse.de> wrote: > > > From: Lee Schermerhorn <lee.schermerh...@hp.com> > > > > NOTE: Once again there is a lot of patch stealing and the end result > > is sufficiently different that I had to drop the signed-offs. > > Will re-add if the original authors are ok with that. > > > > This patch adds another mbind() flag to request "lazy migration". The > > flag, MPOL_MF_LAZY, modifies MPOL_MF_MOVE* such that the selected > > pages are marked PROT_NONE. The pages will be migrated in the fault > > path on "first touch", if the policy dictates at that time. > > > > <SNIP> > > Here you are paying a heavy price for the earlier design > mistake, for forking into per arch approach - the NUMA version > of change_protection() had to be open-coded: >
I considered this when looking at the two trees. At the time I also had the option of making change_prot_numa() to be a wrapper around change_protection() and if pte_numa is made generic, that becomes more attractive. One of the reasons I went with this version from Andrea's tree is simply because it does less work than change_protect() but what should be sufficient for _PAGE_NUMA. I avoid the TLB flush if there are no PTE updates for example but could shuffle change_protection() and get the same thing. > > include/linux/mm.h | 3 + > > include/uapi/linux/mempolicy.h | 13 ++- > > mm/mempolicy.c | 176 > > ++++++++++++++++++++++++++++++++++++---- > > 3 files changed, 174 insertions(+), 18 deletions(-) > > Compare it to the generic version that Peter used: > > include/uapi/linux/mempolicy.h | 13 ++++++++--- > mm/mempolicy.c | 49 > +++++++++++++++++++++++++++--------------- > 2 files changed, 42 insertions(+), 20 deletions(-) > > and the cleanliness and maintainability advantages are obvious. > > So without some really good arguments in favor of your approach > NAK on that complex approach really. > I will reimplement around change_protection() and see what effect, if any, it has on overhead. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
