Messages in this thread | | | Date | Mon, 18 Dec 2017 15:13:53 +0100 | From | Petr Mladek <> | Subject | Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread |
| |
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
| |