Messages in this thread | | | Date | Thu, 7 Mar 2019 15:41:52 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread |
| |
On (03/06/19 23:22), John Ogness wrote: > On 2019-03-06, Petr Mladek <pmladek@suse.com> wrote: > >> _Both_ categories are important for the user, but their requirements > >> are different: > >> > >> informational: non-disturbing > >> emergency: reliable > > > > Isn't this already handled by the console_level? > > > > The informational messages can be reliably read via syslog, /dev/kmsg. > > They are related to the normal works when the system works well. > > > > The emergency messages (errors, warnings) are printed in emergency > > situations. They are printed as reliably as possible to the console > > because the userspace might not be reliable enough. > > I've never viewed console_level this way. _If_ console_level really is > supposed to define the emergency/informational boundary, all > informational messages are supposed to be handled by userspace, and > console printing's main objective is reliability... then I would change > my proposal such that:
OK, you guys are ahead of me.
FB folks want to have a per-console sysfs knob to dynamically adjust loglevel on each console. The use case is to temporarily set loglevel to, say, debug on fast consoles, gather some data/logs, set loglevel back to less verbose afterwards.
Preserving the existing loglevel behaviour looks right to me.
> - if a console supports write_atomic(), _all_ console printing for that > console would use write_atomic()
Sounds right. But Big-Konsole-Lock looks suspicious.
> - only consoles without write_atomic() will be printing via the > printk-kthread(s) > > IMO, for consoles with write_atomic(), this would increase reliability > over the current mainline implementation. It would also simplify > write_atomic() implementations because they would no longer need to > synchronize against write().
[..] > For those consoles that cannot implement write_atomic() (vt and > netconsole come to mind), or as a transition period until remaining > console drivers have implemented write_atomic(), these would use the > "fallback" of printing fully preemptively in their own kthread using > write().
This sounds concerning. IMHO, netconsole is too important to rely on preemptible printk and scheduler. Especially those netcons which run in "report only when oops_in_progress" mode. Sometimes netconsole is the fastest console available, but preemptible printk may turn it into the slowest one.
-ss
| |