lkml.org 
[lkml]   [2008]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] printk: robustify printk
    On Mon, Aug 11, 2008 at 12:45:26PM +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.

    I am missing something here. Are you suggesting that RCU call out
    when a given CPU has nothing to do, rather than the current behavior
    where rcu_needs_cpu() is invoked when a CPU is being considered for
    dynticks idle mode? My concern with this approach would be races that
    are currently avoided by the fact that calls to rcu_needs_cpu() are
    performed with hardirqs disabled.

    Thanx, Paul

    > ( But that's for a separate cleanup patch i think. )
    >
    > No strong feelings though. Peter, which one do you prefer?
    >
    > Ingo


    \
     
     \ /
      Last update: 2008-08-11 15:25    [W:5.417 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site