aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorHugh Dickins <[email protected]>2016-05-19 17:12:35 -0700
committerLinus Torvalds <[email protected]>2016-05-19 19:12:14 -0700
commitca707239e8a7958ffb1c31737d41cae1a674c938 (patch)
tree37792a1ea8ed942fe0337ffa03ef9bb34329a881 /tools/perf/scripts/python
parent1269019e69a6798db15edea8921f83215ef954d6 (diff)
mm: update_lru_size warn and reset bad lru_size
Though debug kernels have a VM_BUG_ON to help protect from misaccounting lru_size, non-debug kernels are liable to wrap it around: and then the vast unsigned long size draws page reclaim into a loop of repeatedly doing nothing on an empty list, without even a cond_resched(). That soft lockup looks confusingly like an over-busy reclaim scenario, with lots of contention on the lru_lock in shrink_inactive_list(): yet has a totally different origin. Help differentiate with a custom warning in mem_cgroup_update_lru_size(), even in non-debug kernels; and reset the size to avoid the lockup. But the particular bug which suggested this change was mine alone, and since fixed. Make it a WARN_ONCE: the first occurrence is the most informative, a flurry may follow, yet even when rate-limited little more is learnt. Signed-off-by: Hugh Dickins <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Andres Lagar-Cavilla <[email protected]> Cc: Yang Shi <[email protected]> Cc: Ning Qu <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Andres Lagar-Cavilla <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions