On Thu, Apr 23, 2020 at 1:35 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2020/04/22 15:59, Michal Hocko wrote: > >>> 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. > > No! My proposal (which offloads to a deferrable context) avoids doing the > heavy lifting (for printk buffer users) from the printk caller context. I'm > saying that "don't pile up too much backlog onto the printk buffer (by abusing > async printk) in order to make sure that kernel messages which are more > important than reporting OOM victim candidates will be processed immediately". > > dump_tasks() remains definitely a printk() abuser which is capable of pushing > many thousands of printk() messages in one second if async printk were available. > Async printk CANNOT deal with the problem that too much backlog causes important > messages to be delayed for too long. Please read my explanation carefully. > Agreed. Too much oom reports still be a issue even if the printk() is asyn. I think the aysnc printk() won't care about wheter the data is improtant or not, so the user of printk() (even if it is asyn) should have a good management of these data especially if these data may consume all or most of the printk buffer. > Also, Sergey Senozhatsky (printk maintainer) said at > https://lkml.kernel.org/r/20200423015008.GA246741@jagdpanzerIV.localdomain > that it is UNKNOWN when async printk is merged. Async printk is not a > silver-bullet breakthrough. Async printk cannot work without cooperation from > printk() users. Please really stop letting the printk() do the heavy lifting. > -- Thanks Yafang
