• David S. Miller's avatar
    sparc64: Fix physical memory management regressions with large max_phys_bits. · 0dd5b7b0
    David S. Miller authored
    If max_phys_bits needs to be > 43 (f.e. for T4 chips), things like
    DEBUG_PAGEALLOC stop working because the 3-level page tables only
    can cover up to 43 bits.
    
    Another problem is that when we increased MAX_PHYS_ADDRESS_BITS up to
    47, several statically allocated tables became enormous.
    
    Compounding this is that we will need to support up to 49 bits of
    physical addressing for M7 chips.
    
    The two tables in question are sparc64_valid_addr_bitmap and
    kpte_linear_bitmap.
    
    The first holds a bitmap, with 1 bit for each 4MB chunk of physical
    memory, indicating whether that chunk actually exists in the machine
    and is valid.
    
    The second table is a set of 2-bit values which tell how large of a
    mapping (4MB, 256MB, 2GB, 16GB, respectively) we can use at each 256MB
    chunk of ram in the system.
    
    These tables are huge and take up an enormous amount of the BSS
    section of the sparc64 kernel image.  Specifically, the
    sparc64_valid_addr_bitmap is 4MB, and the kpte_linear_bitmap is 128K.
    
    So let's solve the space wastage and the DEBUG_PAGEALLOC problem
    at the same time, by using the kernel page tables (as designed) to
    manage this information.
    
    We have to keep using large mappings when DEBUG_PAGEALLOC is disabled,
    and we do this by encoding huge PMDs and PUDs.
    
    On a T4-2 with 256GB of ram the kernel page table takes up 16K with
    DEBUG_PAGEALLOC disabled and 256MB with it enabled.  Furthermore, this
    memory is dynamically allocated at run time rather than coded
    statically into the kernel image.
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    Acked-by: default avatarBob Picco <bob.picco@oracle.com>
    0dd5b7b0
page_64.h 4.3 KB