Aliasing _PAGE_NUMA and _PAGE_PROTNONE had some convenient properties but it ultimately gave Xen a headache and pisses almost everybody off that looks closely at it. Two discussions on "why this makes sense" is one discussion too many so rather than having a third there is this series. Conceptually it's simple -- use an unused physical address bit for _PAGE_NUMA and make it a 64-bit only feature on x86. This had been avoided before because if the physical address space expands we are back to square one but lets worry about that when it happens unless the x86 maintainers or hardware people warn us that we're about to run headlong into a wall. Testing was minimal -- short lived JVM and autonumabench tests that trigger the relevant paths for NUMA balancing. Functionally it did not die miserably. Performance looks as expected with no major changes. arch/x86/Kconfig | 2 +- arch/x86/include/asm/pgtable.h | 8 +++---- arch/x86/include/asm/pgtable_types.h | 44 ++++++++++++++++++++---------------- mm/memory.c | 12 ---------- 4 files changed, 29 insertions(+), 37 deletions(-) -- 1.8.4.5 -- 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>