• David Gibson's avatar
    powerpc/mm: Allow more flexible layouts for hugepage pagetables · a4fe3ce7
    David Gibson authored
    Currently each available hugepage size uses a slightly different
    pagetable layout: that is, the bottem level table of pointers to
    hugepages is a different size, and may branch off from the normal page
    tables at a different level.  Every hugepage aware path that needs to
    walk the pagetables must therefore look up the hugepage size from the
    slice info first, and work out the correct way to walk the pagetables
    accordingly.  Future hardware is likely to add more possible hugepage
    sizes, more layout options and more mess.
    
    This patch, therefore reworks the handling of hugepage pagetables to
    reduce this complexity.  In the new scheme, instead of having to
    consult the slice mask, pagetable walking code can check a flag in the
    PGD/PUD/PMD entries to see where to branch off to hugepage pagetables,
    and the entry also contains the information (eseentially hugepage
    shift) necessary to then interpret that table without recourse to the
    slice mask.  This scheme can be extended neatly to handle multiple
    levels of self-describing "special" hugepage pagetables, although for
    now we assume only one level exists.
    
    This approach means that only the pagetable allocation path needs to
    know how the pagetables should be set out.  All other (hugepage)
    pagetable walking paths can just interpret the structure as they go.
    
    There already was a flag bit in PGD/PUD/PMD entries for hugepage
    directory pointers, but it was only used for debug.  We alter that
    flag bit to instead be a 0 in the MSB to indicate a hugepage pagetable
    pointer (normally it would be 1 since the pointer lies in the linear
    mapping).  This means that asm pagetable walking can test for (and
    punt on) hugepage pointers with the same test that checks for
    unpopulated page directory entries (beq becomes bge), since hugepage
    pointers will always be positive, and normal pointers always negative.
    
    While we're at it, we get rid of the confusing (and grep defeating)
    #defining of hugepte_shift to be the same thing as mmu_huge_psizes.
    Signed-off-by: default avatarDavid Gibson <dwg@au1.ibm.com>
    Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    a4fe3ce7
hash_utils_64.c 32.5 KB