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_. 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. This is what the async printk will address AFAIU. That being said, this is not the first time we are in this discussion and I find repeating the same thing unproductive. -- Michal Hocko SUSE Labs
