On 2020/10/13 0:41, Michal Hocko wrote:
>> 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.
>
Here is one of past discussions.
https://lkml.kernel.org/r/7de2310d-afbd-e616-e83a-d75103b986c6@xxxxxxxxxxxxxxxxxxx
https://lkml.kernel.org/r/20190830103504.GA28313@xxxxxxxxxxxxxx
https://lkml.kernel.org/r/57be50b2-a97a-e559-e4bd-10d923895f83@xxxxxxxxxxxxxxxxxxx
Michal Hocko complained about different OOM domains, and now just ignores it...
Proper ratelimiting for OOM messages had better not to count on asynchronous printk().
