lkml.org 
[lkml]   [2009]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4] softlockup: remove hung_task_check_count
    Peter Zijlstra (peterz@infradead.org) wrote:
    > On Tue, 2009-01-27 at 10:48 -0800, Mandeep Singh Baines wrote:
    > > Ingo Molnar (mingo@elte.hu) wrote:
    > > >
    > > > * Mandeep Singh Baines <msb@google.com> wrote:
    > > >
    > > > > The design was proposed by Frédéric Weisbecker. Peter Zijlstra suggested
    > > > > the use of RCU.
    > > >
    > > > ok, this looks _much_ cleaner.
    > > >
    > > > One question:
    > > >
    > > > > - read_lock(&tasklist_lock);
    > > > > + rcu_read_lock();
    > > > > do_each_thread(g, t) {
    > > > > - if (!--max_count)
    > > > > + if (need_resched())
    > > > > goto unlock;
    > > >
    > > > Isnt it dangerous to skip a check just because we got marked for
    > > > reschedule? Since it runs so rarely it could by accident be preempted and
    > > > we'd not get any checking done for a long time.
    > > >
    > >
    > > Yeah, the checking could be deferred indefinitely. So you could have a system
    > > where tasks are hung but it takes a really long time to detect this and
    > > finally panic the system. Not so good for high-availability.
    >
    > Why break out at all? Are you that worried about khungtaskd introducing
    > latencies?

    Yes, I was worried about disabling preemption for an unbounded amount of
    time.

    > Is using preemptible RCU an option for you?
    >

    I had not even considered that. To be honest, I had not even heard of it
    till now. So I spent another morning at LWN grokking preemptible RCU;)

    I think it can work. I'm a little worried about the OOM risk. It could take
    a really long time to iterate over the task list. A lot of pending kfree()s
    could build up in that time.

    I'm still unclear as to whether khungtaskd would get priority boosted
    or not. Are only tasks that explicitly block (by sleeping on a lock)
    boostable or would a task which got pre-empted inside the critical section
    also be boostable? My worry here is khungtaskd would run at high priority for
    an indefinite amount of time making it more overhead. Is there an OOMing-soon
    booster?

    But I think this can all be mitigated by adding back the max_count sysctl.
    But preemptible RCU would allow increasing the default to a much higher
    value or we may even be able to make the default "check all tasks".

    Running out of time today but I'll send out a patch tomorrow.

    Thanks Peter!

    Regards,
    Mandeep
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-01-29 02:45    [W:3.508 / U:0.508 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site