• Christophe Leroy's avatar
    powerpc/8xx: Manage 512k huge pages as standard pages. · b250c8c0
    Christophe Leroy authored
    At the time being, 512k huge pages are handled through hugepd page
    tables. The PMD entry is flagged as a hugepd pointer and it
    means that only 512k hugepages can be managed in that 4M block.
    However, the hugepd table has the same size as a normal page
    table, and 512k entries can therefore be nested with normal pages.
    
    On the 8xx, TLB loading is performed by software and allthough the
    page tables are organised to match the L1 and L2 level defined by
    the HW, all TLB entries have both L1 and L2 independent entries.
    It means that even if two TLB entries are associated with the same
    PMD entry, they can be loaded with different values in L1 part.
    
    The L1 entry contains the page size (PS field):
    - 00 for 4k and 16 pages
    - 01 for 512k pages
    - 11 for 8M pages
    
    By adding a flag for hugepages in the PTE (_PAGE_HUGE) and copying it
    into the lower bit of PS, we can then manage 512k pages with normal
    page tables:
    - PMD entry has PS=11 for 8M pages
    - PMD entry has PS=00 for other pages.
    
    As a PMD entry covers 4M areas, a PMD will either point to a hugepd
    table having a single entry to an 8M page, or the PMD will point to
    a standard page table which will have either entries to 4k or 16k or
    512k pages. For 512k pages, as the L1 entry will not know it is a
    512k page before the PTE is read, there will be 128 entries in the
    PTE as if it was 4k pages. But when loading the TLB, it will be
    flagged as a 512k page.
    
    Note that we can't use pmd_ptr() in asm/nohash/32/pgtable.h because
    it is not defined yet.
    
    In ITLB miss, we keep the possibility to opt it out as when kernel
    text is pinned and no user hugepages are used, we can save several
    instruction by not using r11.
    
    In DTLB miss, that's just one instruction so it's not worth bothering
    with it.
    Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/002819e8e166bf81d24b24782d98de7c40905d8f.1589866984.git.christophe.leroy@csgroup.eu
    b250c8c0
pgtable.c 10.9 KB