summaryrefslogtreecommitdiffstats
path: root/lib/assoc_array.c
diff options
context:
space:
mode:
authorJohannes Weiner <hannes@cmpxchg.org>2019-11-05 21:16:51 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2019-11-06 08:47:50 -0800
commit1be334e5c0886197cc82923ff0ac5836111b7b57 (patch)
tree9bc1c0af912b0b630c6ca69a2466705dc00785fd /lib/assoc_array.c
parentec649c9d454ea372dcf16cccf48250994f1d7788 (diff)
downloadlinux-1be334e5c0886197cc82923ff0ac5836111b7b57.tar.bz2
mm/page_alloc.c: ratelimit allocation failure warnings more aggressively
While investigating a bug related to higher atomic allocation failures, we noticed the failure warnings positively drowning the console, and in our case trigger lockup warnings because of a serial console too slow to handle all that output. But even if we had a faster console, it's unclear what additional information the current level of repetition provides. Allocation failures happen for three reasons: The machine is OOM, the VM is failing to handle reasonable requests, or somebody is making unreasonable requests (and didn't acknowledge their opportunism with __GFP_NOWARN). Having the memory dump, a callstack, and the ratelimit stats on skipped failure warnings should provide enough information to let users/admins/developers know whether something is wrong and point them in the right direction for debugging, bpftracing etc. Limit allocation failure warnings to one spew every ten seconds. Link: http://lkml.kernel.org/r/20191028194906.26899-1-hannes@cmpxchg.org Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib/assoc_array.c')
0 files changed, 0 insertions, 0 deletions