On 31/03/14 16:41, Linus Torvalds wrote: > On Mon, Mar 31, 2014 at 5:26 AM, Mel Gorman <mgorman@xxxxxxx> wrote: >> >> Ok, so how do you suggest that _PAGE_NUMA could have been implemented >> that did *not* use _PAGE_PROTNONE on x86, trapped a fault and was not >> expensive as hell to handle? > > So on x86, the obvious model is to use another bit. We've got several. > The _PAGE_NUMA case only matters for when _PAGE_PRESENT is clear, and > when that bit is clear the hardware doesn't care about any of the > other bits. Currently we use: > > #define _PAGE_BIT_PROTNONE _PAGE_BIT_GLOBAL > #define _PAGE_BIT_FILE _PAGE_BIT_DIRTY > > which are bits 8 and 6 respectively, afaik. > > and the only rule is that (a) we should *not* use a bit we already use > when the page is not present (since that is ambiguous!) and (b) we > should *not* use a bit that is used by the swap index cases. I think > bit 7 should work, but maybe I missed something. I don't think it's sufficient to avoid collisions with bits used only with P=0. The original value of this bit must be retained when the _PAGE_NUMA bit is set/cleared. Bit 7 is PAT[2] and whilst Linux currently sets up the PAT such that PAT[2] is a 'don't care', there has been talk up adjusting the PAT to include more types. So I'm not sure it's a good idea to use bit 7. What's wrong with using e.g., bit 62? And not supporting this NUMA rebalancing feature on 32-bit non-PAE builds? David > Can somebody tell me why _PAGE_NUMA is *not* that bit seven? Make > "pte_present()" on x86 just check all of the present/numa/protnone > bits, and if any of them is set, it's a "present" page. > > Now, unlike x86, some other architectures do *not* have free bits, so > there may be problems elsewhere. > > Linus -- 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>