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

[Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>]

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.

>                                              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. Rather, async printk might increase the amount of the output (because
it allows printk() users to think as if printk() is so fast).  Shifting to a
deferrable context (like a workqueue) allows reducing the amount of the output.
To shift to a deferrable context, this patch (which maintains state of
not-yet-reported OOM victim candidates) is the first step.

> 
> That being said, this is not the first time we are in this discussion
> and I find repeating the same thing unproductive.

Your repeating refusal is really unproductive.