On Mon 2017-12-18 22:39:48, Sergey Senozhatsky wrote:
> On (12/18/17 14:31), Petr Mladek wrote:
> > On Mon 2017-12-18 18:36:15, Sergey Senozhatsky wrote:
> > > On (12/15/17 10:08), Petr Mladek wrote:
> > > 1) it opens both soft and hard lockup vectors
> > >
> > > I see *a lot* of cases when CPU that call printk in a loop does not
> > > end up flushing its messages. And the problem seems to be - preemption.
> > >
> > >
> > > CPU0 CPU1
> > >
> > > for_each_process_thread(g, p)
> > > printk()
> >
> > You print one message for each process in a tight loop.
> > Is there a code like this?
>
> um... show_state() -> show_state_filter()?
> which prints million times more info than a single line per-PID.
Good example. Heh, it already somehow deals with this:
void show_state_filter(unsigned long state_filter)
{
struct task_struct *g, *p;
rcu_read_lock();
for_each_process_thread(g, p) {
/*
* reset the NMI-timeout, listing all files on a slow
* console might take a lot of time:
* Also, reset softlockup watchdogs on all CPUs, because
* another CPU might be blocked waiting for us to process
* an IPI.
*/
touch_nmi_watchdog();
touch_all_softlockup_watchdogs();
if (state_filter_match(state_filter, p))
sched_show_task(p);
One question is if we really want to rely on offloading in
this case. What if this is printed to debug some stalled
system.
Best Regards,
Petr
