On Sat, Feb 20, 2016 at 10:11:14PM +0530, Aneesh Kumar K.V wrote: > Paul Mackerras <pau...@samba.org> writes: > > > This changes _PAGE_PRESENT for 64-bit Book 3S processors from 0x2 to > > 0x8000_0000_0000_0000, because that is where PowerISA v3.0 CPUs in > > radix mode will expect to find it. > > All the changes in this patch related to _PAGE_PRESENT movement or are > they cleanup that got added to this patch. I am looking at the hpte slot > array changes and wondering how that is related to _PAGE_PRESENT.
I was preserving the property mentioned in this comment: > > /* > > * The linux hugepage PMD now include the pmd entries followed by the > > address > > * to the stashed pgtable_t. The stashed pgtable_t contains the hpte bits. > > - * [ 1 bit secondary | 3 bit hidx | 1 bit valid | 000]. We use one byte per > > + * [ 000 | 1 bit secondary | 3 bit hidx | 1 bit valid]. We use one byte per > > * each HPTE entry. With 16MB hugepage and 64K HPTE we need 256 entries and > > * with 4K HPTE we need 4096 entries. Both will fit in a 4K pgtable_t. > > * > > - * The last three bits are intentionally left to zero. This memory location > > + * The top three bits are intentionally left as zero. This memory location > > * are also used as normal page PTE pointers. So if we have any pointers > > * left around while we collapse a hugepage, we need to make sure > > * _PAGE_PRESENT bit of that is zero when we look at them I don't know if this comment still applies, but now that _PAGE_PRESENT is the top bit of a byte rather than one of the low bits, then to avoid having _PAGE_PRESENT overlap these HPTE location bits in a byte, we need to move the location bits. It seems pretty bogus to me that we might interpret an array of these bytes as a PTE, and if you're sure we never do that, we can drop this change (and the now-misleading comment). Paul. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
