On 6/18/12 4:11 PM, Eric Sandeen wrote:

On 6/18/12 1:25 PM, Andreas Dilger wrote:

quoted

On 2012-06-18, at 6:08 AM, Christoph Hellwig wrote:

quoted

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?

Maybe I'm wrong about that, and we already have IRQ stacks on x86_64 -
at least based on the kernel documentation?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs