On (12/19/17 09:40), Steven Rostedt wrote: > On Tue, 19 Dec 2017 13:58:46 +0900 > Sergey Senozhatsky <sergey.senozhatsky.w...@gmail.com> wrote: > > > so you are not convinced that my scenarios real/matter; I'm not > > Well, not with the test module. I'm looking for actual code in the > upstream kernel. > > > convinced that I have stable and functional boards with this patch ;) > > seems that we are coming to a dead end. > > Can I ask, is it any worse than what we have today?
that's a really hard question. both the existing printk() and the tweaked printk() have the same thing in common - a) preemption from console_unlock() and b) printk() being way to fast compared to anything else (call_console_drivers() and to preemption latency of console_sem owner). your patch puts some requirements that my workload simply cannot fulfill. so may be if I'll start pushing it towards OOM and so on, then I'll see some difference (but both (a) and (b) still gonna stay true). the thing that really changes everything is offloading to printk_kthread. given that I can't have a tiny logbuf, and that I can't have fast console, and that I can't have tons of printks to chose from and to get advantage of hand off algorithm in any reliable way; I need something more to guarantee that the current console_sem will not be forced to evict all logbuf messages. > > for the record, > > I'm not going to block the patch if you want it to be merged. > > Thanks, I mean it :) -ss