On Fri, Dec 06, 2013 at 12:08:22AM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> > > change_prot_numa should work even if _PAGE_NUMA != _PAGE_PROTNONE. > On archs like ppc64 that don't use _PAGE_PROTNONE and also have > a separate page table outside linux pagetable, we just need to > make sure that when calling change_prot_numa we flush the > hardware page table entry so that next page access result in a numa > fault. > > We still need to make sure we use the numa faulting logic only > when CONFIG_NUMA_BALANCING is set. This implies the migrate-on-fault > (Lazy migration) via mbind will only work if CONFIG_NUMA_BALANCING > is set. > > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx> You're right on that there is no direct dependance on numa balancing and use of prot_none. The BUILD_BUG_ON was to flag very clearly that arches wanting to support automatic NUMA balancing must ensure such things as o _PAGE_NUMA is defined o setting _PAGE_NUMA traps a fault and the fault can be uniquely identified as being a numa hinting fault o that pte_present still returns true for pte_numa pages even though the underlying present bit may be cleared. Otherwise operations like following and copying ptes will get confused o shortly, arches will also need to avoid taking references on pte_numa pages in get_user_pages to account for hinting faults properly I guess the _PAGE_NUMA parts will already be caught by other checks and the rest will fall out during testing so it's ok to remove. Acked-by: Mel Gorman <mgorman@xxxxxxx> -- Mel Gorman SUSE Labs -- 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>