Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

[Sergey Senozhatsky]

On (06/28/17 15:42), Petr Mladek wrote:
[..]
> My head is whirling when thinking about all the per-CPU stuff. It is
> looking for escape. The way is to keep it as simple as possible.
> 
> After all, we should need all this only when there is a flood of
> messages. Otherwise, the messages should be handled immediately
> within atomic_print_limit.
> 
> If there is a flood of messages and we do not sleep inside
> console_unlock(), there should always be a new volunteer that
> would continue with console flushing.
> 
> It the flood stops and the system works, we should have enough
> time to recover. If the system stops working during the flood
> then I am afraid that even the per-CPU kthreads would not help
> much.
> 
> Does this makes sense? Or did my head hide some important aspect
> again?

yeah, I agree and understand that per-CPU printk kthreads
is a bit... too much.

it was just a quick idea and I just gave it a try. but there
are some potential takeaways from the series (not sure if you
looked at the last patches of the series).

with per-CPU kthreads we easily

1) can be quite flexible
   there can be only certain CPUs that will take over printing duty.
   so if you system has, say, IRQ affinity set up or anything else
   that is critical, you can forbid printk offloading to those CPUs.
   so "important" CPUs will not print out more than atomic_limit chars,
   the rest of the job will be handled by "less important" CPUs.

   * this can be achieved with a single printk kthread.
     but still, that's something I haven't thought about before this
     series.


2) can offload printing to other CPUs from vprintk_emit()
   and avoid any of scheduler->timekeeping->etc. paths. which will
   replace printk_deferred().

   * this can be achieved with a single printk kthread as well.
   ** at the same time this kills the direct print out guarantees.


there was something else. but I forgot what was it...

	-ss