On Fri, 8 Sep 2017 15:44:43 -0700 Ram Pai <linux...@us.ibm.com> wrote:
> Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6, > in the 4K backed HPTE pages.These bits continue to be used > for 64K backed HPTE pages in this patch, but will be freed > up in the next patch. The bit numbers are big-endian as > defined in the ISA3.0 > > The patch does the following change to the 4k htpe backed > 64K PTE's format. > > H_PAGE_BUSY moves from bit 3 to bit 9 (B bit in the figure > below) > V0 which occupied bit 4 is not used anymore. > V1 which occupied bit 5 is not used anymore. > V2 which occupied bit 6 is not used anymore. > V3 which occupied bit 7 is not used anymore. > > Before the patch, the 4k backed 64k PTE format was as follows > > 0 1 2 3 4 5 6 7 8 9 10...........................63 > : : : : : : : : : : : : > v v v v v v v v v v v v > > ,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-, > |x|x|x|B|V0|V1|V2|V3|x| | |x|x|................|x|x|x|x| <- primary pte > '_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_' > |S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte > '_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_' > > After the patch, the 4k backed 64k PTE format is as follows > > 0 1 2 3 4 5 6 7 8 9 10...........................63 > : : : : : : : : : : : : > v v v v v v v v v v v v > > ,-,-,-,-,--,--,--,--,-,-,-,-,-,------------------,-,-,-, > |x|x|x| | | | | |x|B| |x|x|................|.|.|.|.| <- primary pte > '_'_'_'_'__'__'__'__'_'_'_'_'_'________________'_'_'_'_' > |S|G|I|X|S |G |I |X |S|G|I|X|..................|S|G|I|X| <- secondary pte > '_'_'_'_'__'__'__'__'_'_'_'_'__________________'_'_'_'_' > > the four bits S,G,I,X (one quadruplet per 4k HPTE) that > cache the hash-bucket slot value, is initialized to > 1,1,1,1 indicating -- an invalid slot. If a HPTE gets > cached in a 1111 slot(i.e 7th slot of secondary hash > bucket), it is released immediately. In other words, > even though 1111 is a valid slot value in the hash > bucket, we consider it invalid and release the slot and > the HPTE. This gives us the opportunity to determine > the validity of S,G,I,X bits based on its contents and > not on any of the bits V0,V1,V2 or V3 in the primary PTE > > When we release a HPTE cached in the 1111 slot > we also release a legitimate slot in the primary > hash bucket and unmap its corresponding HPTE. This > is to ensure that we do get a HPTE cached in a slot > of the primary hash bucket, the next time we retry. > > Though treating 1111 slot as invalid, reduces the > number of available slots in the hash bucket and may > have an effect on the performance, the probabilty of > hitting a 1111 slot is extermely low. > > Compared to the current scheme, the above scheme > reduces the number of false hash table updates > significantly and has the added advantage of releasing > four valuable PTE bits for other purpose. > > NOTE:even though bits 3, 4, 5, 6, 7 are not used when > the 64K PTE is backed by 4k HPTE, they continue to be > used if the PTE gets backed by 64k HPTE. The next > patch will decouple that aswell, and truely release the > bits. > > This idea was jointly developed by Paul Mackerras, > Aneesh, Michael Ellermen and myself. > Acked-by: Balbir Singh <bsinghar...@gmail.com>
