• David S. Miller's avatar
    sparc64: Handle extremely large kernel TLB range flushes more gracefully. · 81a91edb
    David S. Miller authored
    [ Upstream commit a74ad5e6 ]
    
    When the vmalloc area gets fragmented, and because the firmware
    mapping area sits between where modules live and the vmalloc area, we
    can sometimes receive requests for enormous kernel TLB range flushes.
    
    When this happens the cpu just spins flushing billions of pages and
    this triggers the NMI watchdog and other problems.
    
    We took care of this on the TSB side by doing a linear scan of the
    table once we pass a certain threshold.
    
    Do something similar for the TLB flush, however we are limited by
    the TLB flush facilities provided by the different chip variants.
    
    First of all we use an (mostly arbitrary) cut-off of 256K which is
    about 32 pages.  This can be tuned in the future.
    
    The huge range code path for each chip works as follows:
    
    1) On spitfire we flush all non-locked TLB entries using diagnostic
       acceses.
    
    2) On cheetah we use the "flush all" TLB flush.
    
    3) On sun4v/hypervisor we do a TLB context flush on context 0, which
       unlike previous chips does not remove "permanent" or locked
       entries.
    
    We could probably do something better on spitfire, such as limiting
    the flush to kernel TLB entries or even doing range comparisons.
    However that probably isn't worth it since those chips are old and
    the TLB only had 64 entries.
    Reported-by: default avatarJames Clarke <jrtc27@jrtc27.com>
    Tested-by: default avatarJames Clarke <jrtc27@jrtc27.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    81a91edb
ultra.S 24.7 KB