lkml.org 
[lkml]   [2016]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Query] Preemption (hogging) of the work handler
Hello,

On (07/14/16 16:52), Viresh Kumar wrote:
> On 12-07-16, 23:03, Sergey Senozhatsky wrote:
> > so, I'm looking at this thing now:
> >
> > : [ 12.874909] sched: RT throttling activated for rt_rq ffffffc0ac13fcd0 (cpu 0)
> > : [ 12.874909] potential CPU hogs:
> > : [ 12.874909] printk (292)
> >
[..]
> - But before that it dumps the kernel-messages from last boot and the prints
> looked like this:

kmsg_dump()? a wild guess... any chance that you kmsg dumper iterates
log_buf records under logbuf_lock long enough to cause throttling on
other CPU, because printk_kthread is simply has to spin on logbuf_lock?

something like

CPU0 CPU1

console_unlock() kmsg_dump()
{ {
kmsg_dump_get_buffer()
{
spin_lock(&logbuf_lock)

spin_lock(&logbuf_lock) while (....) {
^^^^^^^^^^^^^^ long enough
...
}
spin_unlock(&logbuf_lock)
}
.... }
spin_unlock(&logbuf_lock)

call_console_drivers()

cond_resched()
RT throttling
printk_deferred("RT throttling")
}

-ss


> [ 12.805180] [ 7.919623] **Some Kernel Messages here**
>
> Double time-stamp here, because one was already present in the last KMSG (logs
> from previous boot).
>
> After around 100 lines got printed, we had this throttling messages (without the
> double timestamp), and we continue to print things after it as well.
>
> --
> viresh
>

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