[Top] [All Lists]

Re: XFS status update for May 2012

To: Andreas Dilger <adilger@xxxxxxxxx>
Subject: Re: XFS status update for May 2012
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 19 Jun 2012 11:11:08 +1000
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, "linux-fsdevel@xxxxxxxxxxxxxxx Devel" <linux-fsdevel@xxxxxxxxxxxxxxx>
In-reply-to: <AD997E9D-2C1E-4EE4-80D7-2A5C998B6E9E@xxxxxxxxx>
References: <20120618120853.GA15480@xxxxxxxxxxxxx> <AD997E9D-2C1E-4EE4-80D7-2A5C998B6E9E@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Jun 18, 2012 at 12:25:37PM -0600, Andreas Dilger wrote:
> On 2012-06-18, at 6:08 AM, Christoph Hellwig wrote:
> > May saw the release of Linux 3.4, including a decent sized XFS update.
> > Remarkable XFS features in Linux 3.4 include moving over all metadata
> > updates to use transactions, the addition of a work queue for the
> > low-level allocator code to avoid stack overflows due to extreme stack
> > use in the Linux VM/VFS call chain,
> This is essentially a workaround for too-small stacks in the kernel,
> which we've had to do at times as well, by doing work in a separate
> thread (with a new stack) and waiting for the results?  This is a
> generic problem that any reasonably-complex filesystem will have when
> running under memory pressure on a complex storage stack (e.g. LVM +
> iSCSI), but causes unnecessary context switching.

I've seen no performance issues from the context switching.  The
overhead of them is so small to be unmeasurable most cases, because
a typical allocation already requires context switches for contended
locks and metadata IO....

> Any thoughts on a better way to handle this, or will there continue
> to be a 4kB stack limit

We were blowing 8k stacks on x86-64 with alarming ease. Even the
flusher threads were overflowing.

> and hack around this with repeated kmalloc
> on callpaths for any struct over a few tens of bytes, implementing
> memory pools all over the place, and "forking" over to other threads
> to continue the stack consumption for another 4kB to work around
> the small stack limit?

I mentioned that we needed to consider 16k stacks at last years
Kernel Summit and the response was along the lines of "you've got to
be kidding - fix your broken filesystem". That's the perception you
have to change, and i don't feel like having a 4k stacks battle


Dave Chinner

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