lkml.org 
[lkml]   [2016]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v12 0/3] printk: Make printk() completely async
On Mon 2016-07-11 12:25:11, Viresh Kumar wrote:
> On Fri, May 13, 2016 at 6:18 AM, Sergey Senozhatsky
> <sergey.senozhatsky@gmail.com> 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@linaro.org>
>
> 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 ?

I think that this patch helped only by chance. It causes that any
message without a new line will force printk to the sync mode.
Then it will print even the buffered messages immediately. It
causes printk to behave more or less in the sync mode all the time.

I am still scratching my head about the problem fixed by this patch
and also about suspend problems.

Best Regards,
Petr

\
 
 \ /
  Last update: 2016-07-12 18:41    [W:0.132 / U:1.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site