Messages in this thread | | | Subject | Re: [PATCH] printk: robustify printk | From | Peter Zijlstra <> | Date | Mon, 11 Aug 2008 13:04:00 +0200 |
| |
On Mon, 2008-08-11 at 12:45 +0200, Ingo Molnar wrote: > * Peter Zijlstra <a.p.zijlstra@chello.nl> 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.
RCU depends on the polling to advance the state machine, if you want an event driven state machine, you'd have to drive it from rcu_read_unlock() adding overhead there - and I'm pretty sure you don't want to do that.
So while its a tad ugly to poll for these states, I'm not too worried in these two cases - of course every additional poll needs good justification.
> ( But that's for a separate cleanup patch i think. ) > > No strong feelings though. Peter, which one do you prefer?
I personally prefer this printk_tick() driven one over the RCU driven one because it doesn't trade deadlocks.
| |