On 2020/04/14 23:58, Yafang Shao wrote: >>>>> The OOM ratelimit starts with a slow rate, and it will increase slowly >>>>> if the speed of the console is rapid and decrease rapidly if the speed >>>>> of the console is slow. oom_rs.burst will be in [1, 10] and >>>>> oom_rs.interval will always greater than 5 * HZ. >>>> >>>> I am not against increasing the ratelimit timeout. But this patch seems >>>> to be trying to be too clever. Why cannot we simply increase the >>>> parameters of the ratelimit? >>> >>> I justed worried that the user may complain it if too many >>> oom_kill_process callbacks are suppressed. >> >> This can be a real concern indeed. I'm proposing automated ratelimiting of dump_tasks() at http://lkml.kernel.org/r/1563360901-8277-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx . I believe that automated ratelimiting of dump_tasks() remains necessary even after printk() became asynchronous. >> >>> But considering that OOM burst at the same time are always because of >>> the same reason, >> >> This is not really the case. Please note that many parallel OOM killers >> might happen in memory cgroup setups. >> >>> so I think one snapshot of the OOM may be enough. >>> Simply setting oom_rs with {20 * HZ, 1} can resolve this issue. >> >> Does it really though? The ratelimit doesn't stop the long taking >> output. It simply cannot because the work is already done. >> >> That being said, making the ratelimiting more aggressive sounds more >> like a workaround than an actual fix. So I would go that route only if >> there is no other option. I believe the real problem here is in printk >> being too synchronous here. This is a general problem and something >> printk maintainers are already working on. >> > > Yes, printk being too sync is the real issue. If the printk an be > async, then we don't need to worry about it at all. I strongly disagree. dump_tasks() will needlessly fill printk() log buffer (and potentially loose other kernel messages due to buffer full / disk full). By the way, Petr and Sergey, how is the progress of making printk() asynchronous? When can we expect that work to be merged?
