Re: [nacked] mm-oom-avoid-printk-iteration-under-rcu.patch removed from -mm tree

[Michal Hocko <mhocko@suse.com>]

On Thu 23-04-20 18:22:22, Yafang Shao wrote:
> On Thu, Apr 23, 2020 at 3:34 PM Michal Hocko <mhocko@suse.com> wrote:
[...]
> > > I think the aysnc printk() won't care about wheter the data is
> > > improtant or not, so the user of printk() (even if it is asyn) should
> > > have a good management of these data especially if these data may
> > > consume all or most of the printk buffer.
> >
> > Not sure what you mean here. We do have an option to tune the ring
> > buffer (both size and log levels) and dump_tasks specifically.
> >
> 
> There're drawbacks in both of these two options.

They surely are and they were meant as a workaround until printk is more
capable to handle the data flow which we need.

> printk() is multiple-producer and mutiple-consumer.
> OOM is one of the producers.
> logfile (/var/log/messages) and console are two of the consumers.
> Now let's see the drawback of each option.
> 
> - tune the ring buffer (both size and log levels)
> All the producers are effected.
> For example, if you tune the log levels, then all producers have the
> same loglevel with dump_stack() can't show in the console.

The existing loglevels we use are not really carved in stone and we can
prioritize some more than others. dump_tasks is KERN_INFO already and
this is quite a low priority so you shouldn't really miss much when
omitting it. But I wouldn't mind making it KERN_DEBUG.

> Tuning the size may be not scalable, because we don't know how slow
> the console is and tuning it too big is a waste of memory.
> 
> - tune the dump_tasks specifically （vm.oom_dump_tasks）
> All the consumers are effected.
> The logfile is fast enough, so we expect that these dump_tasks could
> be printed into the logfile.
> The console is so slow that we don't want to print into it.
> A possilbe way to fix it is improve vm.oom_dump_tasks.
>     vm.oom_dump_tasks : 1 - dump into all consumers
>                                          2 - don't dump into console
>                                          0 - don't dump into any of

How would that be implemented. I do not know of a way to tell printk
which consoles to use for the output.  Anyway, isn't this something
that can be configured on the printk level. In other words send only
important information to slow consoles?

> the consumers
> But someone may still needs these dump_tasks from the console.

Well, most people simply do not care. I know a bold statement but it's
been couple of years since I am staring at oom reports on regular bases
and I have used that information only in a very marginal percentage of them.
Sure different people need different stuff but nothing really prevents
people from enabling the feature if they feel like. With an obvious
caveat that it can generate a lot of output and that is not a great fit
for slow consoles.
-- 
Michal Hocko
SUSE Labs