On Thu 2020-05-14 20:23:55, Tetsuo Handa wrote: > On 2020/05/14 17:00, Petr Mladek wrote: > > On Wed 2020-05-13 21:59:23, Tetsuo Handa wrote: > >> On 2020/05/13 21:19, Petr Mladek wrote: > >>> On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote: > >>>> On 2020/05/13 19:49, Michal Hocko wrote: > >>>>> On Wed 13-05-20 12:04:13, Petr Mladek wrote: > >>>>>> What is so special about OOM dump task so that it would deserve such > >>>>>> complications? > >>> > >>>> I don't think dump_tasks() is important information to be printed on > >>>> consoles. > >>>> But since somebody might think dump_tasks() is important information to > >>>> be > >>>> printed on consoles, I suggest switching KERN_NO_CONSOLES using e.g. > >>>> sysctl. > >>> > >>> You might achieve the same with DEBUG loglevel. Or do I miss anything? > >> > >> Use of KERN_DEBUG affects userspace syslog daemon. We will have to ask > >> administrators > >> to configure syslog daemon not to filter KERN_DEBUG messages. And > >> administrators will > >> be bothered by needless KERN_DEBUG messages. Also, > > > > What about using KERN_INFO then? Is there still the same problem? > > dump_tasks() is already using KERN_INFO, and the same problem remains. > KERN_INFO cannot > prevent printk() from printing to consoles unless console loglevel is tuned. > And tuning > console loglevel can prevent all KERN_INFO from printing to consoles. What I > want is a > method for allowing administrators to control whether to print each message > to consoles. > Such method will be by definition controlled via "+ loglevel assigned to each > message".
This does not make much sense to me. KERN_NO_CONSOLES would be another global flag. If you enable/disable its functionality, it would affect all strings with this flag (not only the ones used by OOM killer). I am not going to comment the rest. We are going in circles and I do not know how to better explain my concerns. > Given that said, if KERN_NO_CONSOLES is not acceptable, I have to again > battle against Michal Hocko regarding how to offload OOM-related messages, > like Sergey Senozhatsky estimated > > "I'd say that lockless logbuf probably will land sometime around 5.8+. > Async printk() - unknown." One problem there is a lack of reviewers. Best Regards Petr
