Re: Would you help to tell why async printk solution was not taken to upstream kernel ?

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 5 Mar 2018 11:14:16 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> But I still think that it makes sense to change that "print it all" approach.
> With more clear/explicit watchdog-dependent limits - we do direct printk for
> 1/2 (or 2/3) of a current watchdog threshold value and offload if there is
> more stuff in the logbuf. Implicit "logbuf size * console throughput" is
> harder to understand. Disabling watchdog because of printk is a bit too much
> of a compromise, probably.

If you know the baud rate, logbuf size * console throughput is actually
trivial to calculate.

Let's see. CONFIG_LOG_BUF_SHIFT defaults to 18 (2^18 = 262144).
Lets say we have a slow 9600 baud serial, which would give us:

 262144 * 8 / 9600 = 219 (rounded up).

Thus, the worse case scenario would be 219 seconds to output the entire
buffer. Add 10 seconds more for extra overhead, and then you have 229
second watchdog that should never trigger because of a very slow
console.

(A more common 151200 baud modem would empty the buffer in 14 seconds).

> 
> IOW, is logbuf worth of messages so critically important after all that we
> are ready to jeopardize the system stability?

The stability is only in jeopardy if the watchdogs trigger, right?

-- Steve