xfs
[Top] [All Lists]

Re: XFS thread inflation in 2.6.23rc

To: David Chinner <dgc@xxxxxxx>
Subject: Re: XFS thread inflation in 2.6.23rc
From: Andi Kleen <ak@xxxxxxx>
Date: Wed, 8 Aug 2007 14:22:10 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20070808121359.GP52011508@xxxxxxx>
Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
References: <200708081240.21548.ak@xxxxxxx> <20070808121359.GP52011508@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.9.6
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


<Prev in Thread] Current Thread [Next in Thread>