]> www.infradead.org Git - users/jedix/linux-maple.git/commit
sparc64: Handle extremely large kernel TLB range flushes more gracefully.
authorDavid S. Miller <davem@davemloft.net>
Thu, 27 Oct 2016 16:04:54 +0000 (09:04 -0700)
committerChuck Anderson <chuck.anderson@oracle.com>
Thu, 9 Mar 2017 03:30:04 +0000 (19:30 -0800)
commit749f3557eb9cd64f658ecfb883f3edd457843823
treec05b2e6cf3101dc3f4e67bbd927b2d4fe233a220
parent4c2d8b35ccfeabf3535461c6a2fc5358f5a0dded
sparc64: Handle extremely large kernel TLB range flushes more gracefully.

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.

Orabug: 25499527

Reported-by: James Clarke <jrtc27@jrtc27.com>
Tested-by: James Clarke <jrtc27@jrtc27.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a74ad5e660a9ee1d071665e7e8ad822784a2dc7f)
Signed-off-by: Allen Pais <allen.pais@oracle.com>
arch/sparc/mm/ultra.S