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
