On Mon 12-10-20 17:22:32, Petr Mladek wrote:
> > Add two sysctl entries (vm.oom_dump_ratelimit and
> > vm.oom_dump_ratelimit_burst) to control the rate limiting interval and
> > burst, respectively, of the OOM killer output (oom_kill_process()).
> >
> > These entries are disabled by default and can be enabled during kernel
> > configuration with CONFIG_DUMP_RATELIMIT. They take
> > DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST as their default
> > values.
> >
> > Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@xxxxxxxxxxxxx>
> > ---
> >
> > In some setups, the amount of output that the OOM killer generates when
> > it kills a process and dumps the list of tasks can be too
> > large. Unfortunately, the rate-limiting used for it uses the default
> > values for the rate limit interval and burst. This patch allows the user
> > to configure these values.
>
> It might be pretty hard to set any reasonable values. It depends on
> the console speed and the amount of processes on the system. I wonder
> who many people would be able to use it in reality.
Agreed!
> What about introducing some feedback from the printk code?
>
> static u64 printk_last_report_seq;
>
> if (consoles_seen(printk_last_report_seq)) {
> dump_header();
> printk_last_report_seq = printk_get_last_seq();
> }
>
> By other words. It would skip the massive report when the consoles
> were not able to see the previous one.
I am pretty sure this has been discussed in the past but maybe we really
want to make ratelimit to work reasonably also for larger sections
instead. Current implementation only really works if the rate limited
operation is negligible wrt to the interval. Can we have a ratelimit
alternative with a scope effect (effectivelly lock like semantic)?
if (rate_limit_begin(&oom_rs)) {
dump_header();
rate_limit_end(&oom_rs);
}
rate_limi_begin would act like a try lock with additional constrain on
the period/cadence based on rate_limi_end marked values.
--
Michal Hocko
SUSE Labs
