On Wed, Oct 10, 2018 at 2:25 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Wed 10-10-18 20:48:33, Sergey Senozhatsky wrote: >> On (10/10/18 13:35), Michal Hocko wrote: >> > > Just flooding out of memory messages can trigger RCU stall problems. >> > > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing >> > >> > [...] >> > >> > Quite some of them, indeed! I guess we want to rate limit the output. >> > What about the following? >> >> A bit unrelated, but while we are at it: >> >> I like it when we rate-limit printk-s that lookup the system. >> But it seems that default rate-limit values are not always good enough, >> DEFAULT_RATELIMIT_INTERVAL / DEFAULT_RATELIMIT_BURST can still be too >> verbose. For instance, when we have a very slow IPMI emulated serial >> console -- e.g. baud rate at 57600. DEFAULT_RATELIMIT_INTERVAL and >> DEFAULT_RATELIMIT_BURST can add new OOM headers and backtraces faster >> than we evict them. >> >> Does it sound reasonable enough to use larger than default rate-limits >> for printk-s in OOM print-outs? OOM reports tend to be somewhat large >> and the reported numbers are not always *very* unique. >> >> What do you think? > > I do not really care about the current inerval/burst values. This change > should be done seprately and ideally with some numbers. I think Sergey meant that this place may need to use larger-than-default values because it prints lots of output per instance (whereas the default limit is more tuned for cases that print just 1 line). I've found at least 1 place that uses DEFAULT_RATELIMIT_INTERVAL*10: https://elixir.bootlin.com/linux/latest/source/fs/btrfs/extent-tree.c#L8365 Probably we need something similar here.
