On Wed, Apr 15, 2020 at 1:58 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > Thanks for your information. I haven't read your proposal carefully, but take a first glance I think it would be a useful improvement. > >> > >>> 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). > Yup, printk() log buffer will be a issue if the console is too slow. After the printk() is implemented as async, I thinks it is worth to do some optimization. > By the way, Petr and Sergey, how is the progress of making printk() asynchronous? > When can we expect that work to be merged? > Thanks Yafang
