Re: [PATCH v12 0/3] printk: Make printk() completely async

[Viresh Kumar]

On Fri, May 13, 2016 at 6:18 AM, Sergey Senozhatsky
<sergey.senozhatsky@xxxxxxxxx> wrote:
> Hello,
>
> no code changes, just refreshing the series so it'll be easier to
> pick up. added Reviwed-by-s and corrected a typo spotted by Petr.
>
> This patch permits to change printk() to operate in completely
> asynchronous mode: new messages are getting upended to the kernel
> printk buffer, but instead of 'direct' printing the actual print
> job is performed by a dedicated kthread. This has the advantage
> that printing always happens from a schedulable context and thus
> we don't lockup any particular CPU or even interrupts.
>
> against next-20160513
>
>
> v12:
> -- rename printk_kthread_can_run bool flag
> -- update printk_kthread_can_run comment (Petr)
> -- drop mutex from printk_sync_set(), sysfs writes are synchronised (Petr)

We were also screwed because of the problem this thread is trying to solve,
which I posted last week [1].

And then I found this thread which fixed my issue, thanks a lot guys :)

Tested-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>

Though, I would also like to mention one unwanted thing that happened on
my setup :)

[   12.874909] sched: RT throttling activated for rt_rq ffffffc0ac13fcd0 (cpu 0)
[   12.874909] potential CPU hogs:
[   12.874909]  printk (292)

On my system, the excessive printing happens during suspend/resume and this
happened after all the non-boot CPUs were offlined. So, only CPU 0 was left and
that was doing printing for a long time and so these errors :)

It resulted in missing some print messages eventually as the scheduler probably
didn't schedule this thread for sometime after that.

Will it be fine to get the priority of this kthread to a somewhat lower value,
etc ?

--
viresh

[1] http://marc.info/?l=linux-kernel&m=146739243615687