On (06/30/17 14:11), Petr Mladek wrote:
> > 2) can offload printing to other CPUs from vprintk_emit()
> >and avoid any of scheduler->timekeeping->etc. paths. which will
> >replace printk_deferred().
>
> I probably miss something. There is still called wake_up_process()
> in this patchset a
On Thu 2017-06-29 16:56:30, Sergey Senozhatsky wrote:
> 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
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
On Thu 2017-06-08 17:18:29, Sergey Senozhatsky wrote:
> we still don't have guarantees that printk_kthread will be scheduled on
> a CPU that can run it immediately or anytime in the future, but not too
> late. printk_kthread can even be scheduled on the CPU that has requested
> offloading in the fi
Hello,
On (06/02/17 18:03), Sergey Senozhatsky wrote:
[..]
> I've managed to reproduce some of the issues with a single printk
> kthread solution that Jan Kara talked about. Sometimes scheduler decides
> sometimes scheduler decides that printk kthread should run on the same CPU
> as the proc
5 matches
Mail list logo
