From: Mandeep Singh Baines <msb@google.com>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, rientjes@google.com,
mbligh@google.com, thockin@google.com
Subject: Re: [PATCH v2] softlockup: decouple hung tasks check from softlockup detection
Date: Fri, 16 Jan 2009 20:13:30 -0800 [thread overview]
Message-ID: <20090117041330.GE14946@google.com> (raw)
In-Reply-To: <c62985530901160858j3a8cd7b9o216cda473bc585e9@mail.gmail.com>
Hi Frédéric,
Frédéric Weisbecker (fweisbec@gmail.com) wrote:
> > - read_lock(&tasklist_lock);
> > - do_each_thread(g, t) {
> > - if (!--max_count)
> > - goto unlock;
>
>
> Instead of having this arbitrary limit of tasks, why not just
> lurk the need_resched() and then schedule if it needs too.
>
> I know that sounds a bit racy, because you will have to release the
> tasklist_lock and
> a lot of things can happen in the task list until you become resched.
> But you can do a get_task_struct() on g and t before your thread is
> going to sleep and then put them
> when it is awaken.
> Perhaps some tasks will disappear or be appended in the list before g
> and t, but that doesn't really matter:
> if they disappear, they didn't lockup, and if they were appended, they
> are not enough cold to be analyzed :-)
>
> This way you can drop the arbitrary limit of task number given by the user....
>
> Frederic.
>
Would be nice to remove the limit. But I don't think get_task_struct()
can be used to prevent a task from being unlinked from the task list. It
only prevents the task_struct from being freed. So hung_task could end up
holding a reference to an unlinked task after it returns from schedule().
That doesn't mean what you are suggesting can't be implemented. Just means
that the case of the held task being unlinked needs to be handled.
Regards,
Mandeep
next prev parent reply other threads:[~2009-01-17 4:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-12 6:52 [PATCH v2] softlockup: decouple hung tasks check from softlockup detection Mandeep Singh Baines
2009-01-12 9:03 ` Ingo Molnar
2009-01-12 17:58 ` [PATCH v3] " Mandeep Singh Baines
2009-01-14 10:54 ` Ingo Molnar
2009-01-15 19:08 ` [PATCH v4] " Mandeep Singh Baines
2009-01-16 13:06 ` Ingo Molnar
2009-01-16 13:24 ` Ingo Molnar
2009-01-12 14:32 ` [PATCH v2] " Johannes Weiner
2009-01-16 16:58 ` Frédéric Weisbecker
2009-01-17 4:13 ` Mandeep Singh Baines [this message]
2009-01-17 14:07 ` Frederic Weisbecker
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=20090117041330.GE14946@google.com \
--to=msb@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=mingo@elte.hu \
--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).