[Top] [All Lists]

Re: XFS status update for May 2012

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: XFS status update for May 2012
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 19 Jun 2012 11:27:00 +1000
Cc: Andreas Dilger <adilger@xxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, "linux-fsdevel@xxxxxxxxxxxxxxx Devel" <linux-fsdevel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4FDF9998.6020205@xxxxxxxxxxx>
References: <20120618120853.GA15480@xxxxxxxxxxxxx> <AD997E9D-2C1E-4EE4-80D7-2A5C998B6E9E@xxxxxxxxx> <4FDF9998.6020205@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Jun 18, 2012 at 04:11:52PM -0500, Eric Sandeen wrote:
> On 6/18/12 1:25 PM, 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.
> > 
> > Any thoughts on a better way to handle this, or will there continue
> > to be a 4kB stack limit and hack around this with repeated kmalloc
> well, 8k on x86_64 (not 4k) right?   But still...
> Maybe it's still a partial hack but it's more generic - should we have
> IRQ stacks like x86 has?  (I think I'm right that that only exists
> on x86 / 32-bit) - is there any downside to that?

We already have irq stacks for x86-64 - the stackunwinder knows
about them so when you get a stack trace from the interrupt stack is
walks back across to the thread stack at the appropriate point...

See dump_trace() in arch/x86/kernel/dumpstack_64.c


Dave Chinner

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