Re: [PATCH] mm, oom: enable rate-limiting controls for oom dumps

["Ricardo Cañuelo" <ricardo.canuelo@collabora.com>]

Hi Petr,

Thanks for taking the time to look into this.

On lun 12-10-2020 17:22:32, Petr Mladek wrote: 
> 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.

I agree that the interface is not obvious to use and is very
system-specific. But the idea was to reuse the same parameter interface
already used by printk_ratelimit. There certainly are some users that
want this, but maybe they'd be happy too with another alternative that
mitigates the problem of having too much OOM console output.

> 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.

Thanks for the suggestion. I'll take a closer look at the printk
implementation to see if this is a viable alternative.

> I do not see a reason to have this build configurable. The options are
> either useful or not.

I thought that this feature is maybe too specific to justify having two
new sysctl entries for everyone.

> Why is _interval suffix omitted in the first variable? I find this
> pretty confusing.

The name of the sysctl entries mimics those of printk_ratelimit and
printk_ratelimit_burst, I thought people would be familiar with these
already.

Cheers,
Ricardo