On Wed, Aug 08, 2007 at 02:22:10PM +0200, Andi Kleen wrote:
> 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.
Memory allocation failure + dirty transaction == filesystem shutdown.
Bad, bad, bad, bad.
> > Besides, what's the point of having nice constructs like dedicated
> > workqueues
>
> It's a resource that shouldn't be overused.
A workqueue + thread uses, what, 10-15k of memory? That's the cost of about
10 cached inodes. It is insignificant...
> 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.
Sure, it was written for a small market, but it's useful for other
workloads. e.g. got a heavy tmp file load? Mark /tmp as a filestream
directory and all your temp files end up in one location on disk
and don't pollute and fragment everything else. Got a PVR that
records multiple streams at once? I wouldn't reject this out
of hand as not useful. It was created for the specific purpose
of workload isolation and that can be used in many different
ways....
> > if people complain when they get used to solve problems?
>
> Does XFS really need that many threads? Seems doubtful to me.
XFS is much more threaded than any other linux filesystem.
It does lots of stuff asynchronously and that's where the
threads and workqueues come in. They fit in very closely with
the nature of XFS which is to do as much stuff concurrently as
possible on as many CPUs as possible.
Hmmm. I guess you are really not going to like the patch I
have that moves the AIL pushing to a new thread to solve
some of scalability issues in the transaction subsystem......
> 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.
Agreed, but that is a workqueue implementation detail, not a reason
for preventing ppl from using workqueues.
> But that's a separate issue from just gratuitously adding new ones.
Call it what you will. Threads and workqueues are there to be used
and they cost very little for the flexibility and concurrency they
provide us.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|