From: Andi Kleen <ak@suse.de>
To: David Chinner <dgc@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: XFS thread inflation in 2.6.23rc
Date: Wed, 8 Aug 2007 14:22:10 +0200 [thread overview]
Message-ID: <200708081422.10373.ak@suse.de> (raw)
In-Reply-To: <20070808121359.GP52011508@sgi.com>
On Wednesday 08 August 2007 14:13:59 David Chinner wrote:
> On Wed, Aug 08, 2007 at 12:40:21PM +0200, Andi Kleen wrote:
> >
> > In 2.6.23rc I have a new kernel thread running from XFS:
> >
> > 30137 ? S< 0:00 [xfs_mru_cache]
> >
> > Is that one really needed? Can it be started only on demand when that MRU
> > feature is used?
>
> It uses a single threaded workqueue for reaping objects and the thread comes
> along with that. Creating the workqueue on demand would require creating a
> kernel thread inside a transaction and that's not some thing we want to do.
Why not? I can't think of any possible problem except memory allocation
recursion, but even that should be handled.
> Besides, what's the point of having nice constructs like dedicated
> workqueues
It's a resource that shouldn't be overused.
Especially for such a obscure feature -- i remember reviewing your rationale
for the MRU cache and the probability of this applying to 99.9+% of users ever
is pretty small. If you insist adding such things make them as least
as unobtrusive as possible.
> if people complain when they get used to solve problems?
Does XFS really need that many threads? Seems doubtful to me.
Ok part of the problem is that the workqueues are a little dumb.
e.g. it's highly doubtful per SMT thread workqueues really make any sense.
It would be probably enough to have one per socket or one per node.
But that's a separate issue from just gratuitously adding new ones.
-Andi
next prev parent reply other threads:[~2007-08-08 12:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-08 10:40 XFS thread inflation in 2.6.23rc Andi Kleen
2007-08-08 12:13 ` David Chinner
2007-08-08 12:22 ` Andi Kleen [this message]
2007-08-08 13:14 ` David Chinner
2007-08-08 13:26 ` Andi Kleen
2007-08-09 11:03 ` David Chinner
2007-08-10 19:34 ` Eric Sandeen
2007-08-10 23:49 ` David Chinner
2007-08-11 1:21 ` Eric Sandeen
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=200708081422.10373.ak@suse.de \
--to=ak@suse.de \
--cc=dgc@sgi.com \
--cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.