linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mandeep Singh Baines <msb@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Ingo Molnar" <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	rientjes@google.com, mbligh@google.com, thockin@google.com,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH v4] softlockup: remove hung_task_check_count
Date: Wed, 28 Jan 2009 17:42:45 -0800	[thread overview]
Message-ID: <20090129014245.GM22298@google.com> (raw)
In-Reply-To: <1233131100.10992.43.camel@laptop>

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

  reply	other threads:[~2009-01-29  1:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-25 20:50 [RFC][PATCH 2/2] add a counter for writers spinning on a rwlock Frederic Weisbecker
2009-01-26 13:32 ` Ingo Molnar
2009-01-26 13:48 ` Peter Zijlstra
2009-01-26 15:25   ` Frédéric Weisbecker
2009-01-26 15:37     ` Peter Zijlstra
2009-01-26 16:04       ` Frédéric Weisbecker
2009-01-26 17:36         ` Mandeep Baines
2009-01-26 17:41           ` Peter Zijlstra
2009-01-27  0:30             ` [PATCH v4] softlockup: remove hung_task_check_count Mandeep Singh Baines
2009-01-27  9:27               ` Frederic Weisbecker
2009-01-27 13:26               ` Ingo Molnar
2009-01-27 18:48                 ` Mandeep Singh Baines
2009-01-28  8:25                   ` Peter Zijlstra
2009-01-29  1:42                     ` Mandeep Singh Baines [this message]
2009-01-30 20:41                       ` Mandeep Singh Baines
2009-01-30 20:46                       ` [PATCH 1/2] softlockup: convert read_lock in hung_task to rcu_read_lock Mandeep Singh Baines
2009-01-30 20:49                       ` [PATCH 2/2] softlockup: check all tasks in hung_task Mandeep Singh Baines
2009-01-31 19:22                         ` Peter Zijlstra
2009-02-03  0:05                           ` [PATCH 2/2 v2] " Mandeep Singh Baines
2009-02-03 12:23                             ` Ingo Molnar
2009-02-03 20:56                               ` [PATCH 2/2 v3] " Mandeep Singh Baines
2009-02-04 19:43                                 ` Ingo Molnar
2009-02-05  4:35                                   ` [PATCH 2/2 v4] " Mandeep Singh Baines
2009-02-05 14:34                                     ` Ingo Molnar
2009-02-05 17:48                                       ` Andrew Morton
2009-02-05 18:07                                         ` Ingo Molnar
2009-02-05 18:30                                           ` Andrew Morton
2009-02-05 18:58                                             ` Ingo Molnar
2009-02-05 18:40                                         ` Mandeep Singh Baines
2009-02-05 17:56                                       ` [PATCH] softlockup: convert read_lock in hung_task to rcu_read_lock Mandeep Singh Baines
2009-02-05 18:13                                         ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090129014245.GM22298@google.com \
    --to=msb@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@google.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=thockin@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).