On Fri, Dec 06, 2013 at 12:08:22AM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> > > 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.ku...@linux.vnet.ibm.com>
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 <mgor...@suse.de> -- Mel Gorman SUSE Labs _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
