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

[Michal Hocko <mhocko@suse.com>]

On Wed 22-04-20 15:40:19, Tetsuo Handa wrote:
> On 2020/04/20 16:33, Michal Hocko wrote:
> > On Sat 18-04-20 19:13:57, Tetsuo Handa wrote:
> > [...]
> >>> For the specific issue that you are pointing out, a simple and working
> >>> workaround is to reduce the loglevel or disable dump_tasks. There is no
> >>> real reason to add ugly kluges IMHO.
> >>
> >> I do need dump_tasks() output in order to understand memory usage as of
> >> invocation of the OOM killer (rather than verifying whether the OOM killer
> >> chose appropriate OOM victim). I really do not want to reduce the loglevel
> >> or disable dump_tasks().
> >>
> >> You are misunderstanding the problem. Asynchronous printk() cannot solve a problem
> >> that printk() buffer is needlessly flooded with OOM related messages, which can
> >> result in loss of non OOM-related messages if console is slow and can result in
> >> bloating of log files if console is not slow.
> > 
> > I do agree with this statement. And that is the _primamry_ point why I
> > believe your patch doesn't solve _anything_.
> 
> This patch does avoid RCU stall problem.

Which has been observed only under artificial oom hammering which
doesn't resemble any real life workload AFAIR. So while I agree that RCU
stall is annoying it is not worth addressing with the invasive change
you are proposing. This is a simple matter of cost vs. benefit
evaluation.

> >                                              Why? Because it doesn't
> > reduce the amount of the output. You merely shift it to a different
> > context which adds complexity as I've mentioned already. The only thing
> > you really "fix" is that the potentially long taking printk is not done
> > from the locked oom context.
> 
> "The potentially long taking printk is not done from the locked oom context"
> is an improvement (which we can do without waiting for async printk changes).
> 
> >                              This is what the async printk will address
> > AFAIU.
> 
> No! You are completely wrong!! Async printk CANNOT reduce the amount of the
> output.

Which is exactly what I claim above. Async printk would, however, deal
with the problem of the locked context part of the problem because
the heavy lifting is not done from the caller context. Please read my
response carefully.

> Rather, async printk might increase the amount of the output (because
> it allows printk() users to think as if printk() is so fast).

You make no sense.

This is just waste of time (again). I am done with this thread.
-- 
Michal Hocko
SUSE Labs