On Tue, Apr 14, 2020 at 10:32 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>
> On Tue 14-04-20 20:32:54, Yafang Shao wrote:
> > On Tue, Apr 14, 2020 at 3:39 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> [...]
> > > Besides that I strongly suspect that you would be much better of
> > > by disabling /proc/sys/vm/oom_dump_tasks which would reduce the amount
> > > of output a lot. Or do you really require this information when
> > > debugging oom reports?
> > >
> >
> > Yes, disabling /proc/sys/vm/oom_dump_tasks can save lots of time.
> > But I'm not sure whehter we can disable it totally, because disabling
> > it would prevent the tasks log from being wrote into /var/log/messages
> > neither.
>
> Yes, eligible tasks would be really missing. The real question is
> whether you are really going to miss that information. From my
> experience of looking into oom reports for years I can tell that the
> list might be useful but in a vast majority of cases I simply do not
> really neeed it because the stat of memory and chosen victims are much
> more important. The list of tasks is usually interesting only when you
> want to double check whether the victim selection was reasonable or
> cases where a list of tasks itself can tell whether something went wild
> in the userspace.
>
Agreed. From my experience, the list of tasks is mainly used to double
check the oom score.
> > > > 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.
>
> > 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.
> For now I would recommend to workaround this problem by reducing the log
> level or disabling dump_tasks.
>
Reducing the log level is what we have been doing.
Many thanks for your patient explaination.
Thanks
Yafang
