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/18 0:26, Michal Hocko wrote:
> On Fri 17-04-20 23:33:41, Tetsuo Handa wrote:
>> On 2020/01/31 13:33, akpm@linux-foundation.org wrote:
>>> The patch titled
>>>      Subject: mm, oom: avoid printk() iteration under RCU
>>> has been removed from the -mm tree.  Its filename was
>>>      mm-oom-avoid-printk-iteration-under-rcu.patch
>>>
>>> This patch was dropped because it was nacked
>>
>> This patch was once nacked by Michal Hocko. But based on
>> https://lkml.kernel.org/r/CALOAHbArHa-QZ2hXnLOhEJ3Ti=C69-LPtjZB9zqPcuTKeHsV4g@mail.gmail.com
>> that dump_tasks() will become a real world problem with slow consoles (even if
>> printk() becomes asynchronous), I propose you to revive this patch as a first step for
>> implementing workable ratelimit for dump_tasks(). This patch can be applied as-is
>> on current linux.git and linux-next.git (only offset difference).
> 
> My nack still applies. Slow consoles are really a pain and they are
> going to be addressed by the upcoming printk work from a large part.
> Your patch doesn't address the problem it merely shift it around while
> making code even more obscure and harder to maintain.

Your nack is wrong. The upcoming printk work will not address the problem.

> 
> 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. My proposal is to minimize duplicated
OOM-related messages by keeping dump_task() synchronous (even if printk() becomes
asynchronous) by offloading the printing to a workqueue context. This patch is the
first step for making it possible to offload the printing to a workqueue context.
Waiting for printk() to become asynchronous is completely irrelevant.