mirror of https://gitee.com/openkylin/linux.git
a74ad5e660
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: James Clarke <jrtc27@jrtc27.com> Tested-by: James Clarke <jrtc27@jrtc27.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| .. | ||
| Makefile | ||
| extable.c | ||
| fault_32.c | ||
| fault_64.c | ||
| gup.c | ||
| highmem.c | ||
| hugetlbpage.c | ||
| hypersparc.S | ||
| init_32.c | ||
| init_64.c | ||
| init_64.h | ||
| io-unit.c | ||
| iommu.c | ||
| leon_mm.c | ||
| mm_32.h | ||
| srmmu.c | ||
| srmmu_access.S | ||
| swift.S | ||
| tlb.c | ||
| tsb.c | ||
| tsunami.S | ||
| ultra.S | ||
| viking.S | ||