aboutsummaryrefslogtreecommitdiff
path: root/lib/dump_stack.c
diff options
context:
space:
mode:
authorJohannes Weiner <[email protected]>2019-11-05 21:16:51 -0800
committerLinus Torvalds <[email protected]>2019-11-06 08:47:50 -0800
commit1be334e5c0886197cc82923ff0ac5836111b7b57 (patch)
tree9bc1c0af912b0b630c6ca69a2466705dc00785fd /lib/dump_stack.c
parentec649c9d454ea372dcf16cccf48250994f1d7788 (diff)
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/[email protected] Signed-off-by: Johannes Weiner <[email protected]> Acked-by: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'lib/dump_stack.c')
0 files changed, 0 insertions, 0 deletions