Hi John, On 4/7/22 16:35, John Ogness wrote: > On 2022-04-07, Helge Deller <deller@xxxxxx> wrote: >>>> - emergency reboot/shutdown >>>> - cpu and rcu stalls >>>> - hard and soft lockups >>>> - hung tasks >>>> - warn >>>> - sysrq >> >> I agree that those needs direct printing. >> Did you maybe checked how much (e.g. in percentage) of a normal log is >> then still left to be printed threadened? Just in case it's not much, >> is there still a benefit to introduce threadened printing? > > A "normal" log can still contain many many messages. There have been > reports [0] where the system died because _printk_ killed it. This was > not any of the scenarios that we want direct printing for. It was just a > lot of messages that some driver wanted to output. > > Until now the response was always to reduce printk usage or avoid it > altogether. printk has a bad reputation because it is so unpredictable > and expensive. So we are fixing printk. With threaded printers, we make > a dramatic change. printk becomes 100% lockless and consistently quite > fast. You can use it to debug or log messages within any code in the > kernel and not need to worry about horrible latencies being introduced. > > For drivers that start dumping tons of messages, there is no concern > that the system will die because of the messages. Thank you for this good explanation! In my case - while I debug low-level kernel code - I then just need to use pr_warn() or pr_emerg() and get it printed non-threadened. That's sufficient for me. >> Or another example, e.g. when running on a slow console (the best >> testcase I know of is a 9600 baud serial port), where some printks are >> threadened. Then a warn printk() has to be shown, doesn't it mean all >> threadened printks have to be flushed (waited for) until the warning >> can be shown. Will there then still be a measureable time benefit? > > Now you are talking about something else, unrelated to the threaded > printing. A warn is considered a serious non-normal event. In this case, > printk temporarily falls back to the direct, slow, unpredictable, > printk-caller-context behavior we know today. Good. > If we see that direct printing is being used during normal operation > (i.e. developers are performing warns just for fun), then we should not > mark warns for direct printing. We will need to get some real-world > experience here, but the goal is that systems do not use direct printing > unless a real serious emergency is going on. Otherwise, the system risks > dying because of the messages rather than the problem being reported. I agree, it's good if this gets fixed at some point. Thanks! Helge > John > > [0] https://lore.kernel.org/all/20190306171943.12345598@xxxxxxxxxxxxxxxx
