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. 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.
