[lkml]   [2008]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] printk: robustify printk

* Peter Zijlstra <> wrote:

> On Fri, 2008-08-08 at 21:21 +0200, Peter Zijlstra wrote:
> > The initial printk_tick() based implementation didn't suffer this
> > problem, should we revert to that scheme?
> Just in case people care..
> ---
> Subject: printk: robustify printk
> Avoid deadlocks against rq->lock and xtime_lock by deferring the klogd
> wakeup by polling from the timer tick.

i missed most of the discussion, but this seems like the simplest (and
hence ultimately the best) approach to me.

Coupling printk with RCU, albeit elegant, does not seem like the right
choice to me in this specific case: printk as an essential debug
mechanism should be as decoupled as possible.

Also, once we accept the possibility of async klogd completion, we might
as well do it all the time.

i have only one sidenote:

> --- linux-2.6.orig/kernel/time/tick-sched.c
> +++ linux-2.6/kernel/time/tick-sched.c
> @@ -255,7 +255,7 @@ void tick_nohz_stop_sched_tick(int inidl
> next_jiffies = get_next_timer_interrupt(last_jiffies);
> delta_jiffies = next_jiffies - last_jiffies;
> - if (rcu_needs_cpu(cpu))
> + if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu))
> delta_jiffies = 1;

this change made a previous design quirks even more visible: these are
items that are not purely event driven but need some polling component.
RCU is one, and now printk is another.

We could clean this up further by integrating the rcu_needs_cpu() and
printk_needs_cpu() into a softirq mechanism. We already check for
pending softirqs in tick-sched.c, so the above complication would go
away completely.

( But that's for a separate cleanup patch i think. )

No strong feelings though. Peter, which one do you prefer?


 \ /
  Last update: 2008-08-11 12:49    [W:0.276 / U:3.392 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site