[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090127184851.GD22298@google.com>
Date: Tue, 27 Jan 2009 10:48:51 -0800
From: Mandeep Singh Baines <msb@...gle.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Frédéric Weisbecker <fweisbec@...il.com>,
rientjes@...gle.com, mbligh@...gle.com, thockin@...gle.com,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v4] softlockup: remove hung_task_check_count
Ingo Molnar (mingo@...e.hu) wrote:
>
> * Mandeep Singh Baines <msb@...gle.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.
What if a check_count sysctl was added? But instead of being a max_check_count,
it would be a min_check_count. This would guarantee that a minimum amount of
checking is done.
Alternatively, the code for trying to continue the iteration after a
reschedule could be re-inserted. That code is a little tricky and
potentially fragile since continuation of a tasklist iteration is not
really supported by the sched.h APIs. But it is does have the nice properties
of getting through the entire list almost all the time and still playing nice
with the scheduler.
Regards,
Mandeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists