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@xxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx >> 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.
