On 2020/05/13 19:04, Petr Mladek wrote: >> What is wrong with adding NO_CONSOLES ? > > How does it differ from KERN_DEBUG? The debug messages: > > + can be disabled via sysfs > + might reach console when this loglevel is enabled
KERN_NO_CONSOLES is different from KERN_DEBUG in that KERN_NO_CONSOLES itself does not affect userspace daemon's judgement (whether to filter KERN_$LOGLEVEL messages). > What is so special about OOM dump task so that it would deserve such > complications? OOM dump task is special in that it can generate thousands of KERN_INFO messages. If such messages are printed to consoles, it defers solving OOM situation. But setting /proc/sys/vm/oom_dump_tasks to 0 causes such messages being not delivered to userspace daemon for later analysis. Therefore, we can not set /proc/sys/vm/oom_dump_tasks to 0 if we want to save such messages for later analysis. Changing console loglevel (e.g. setting "quiet" kernel command line option) in order to hide such messages also prevents all other KERN_INFO messages from being printed to consoles. Since some KERN_INFO messages are worth printing to consoles while other KERN_INFO messages are worth printing to consoles, controlling with > + loglevel assigned to each message is inevitable. I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth printing to consoles and the rest messages do not worth printing to consoles. Existing KERN_$LOGLEVEL is too rough-grained.
