From: Eric Sandeen <sandeen@sandeen.net>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Christoph Hellwig <hch@infradead.org>,
"linux-fsdevel@vger.kernel.org Devel"
<linux-fsdevel@vger.kernel.org>,
xfs@oss.sgi.com
Subject: Re: XFS status update for May 2012
Date: Mon, 18 Jun 2012 16:16:12 -0500 [thread overview]
Message-ID: <4FDF9A9C.6060408@sandeen.net> (raw)
In-Reply-To: <4FDF9998.6020205@sandeen.net>
On 6/18/12 4:11 PM, 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?
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
next prev parent reply other threads:[~2012-06-18 21:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-18 12:08 XFS status update for May 2012 Christoph Hellwig
2012-06-18 18:25 ` Andreas Dilger
2012-06-18 18:43 ` Ben Myers
2012-06-18 20:36 ` Andreas Dilger
2012-06-19 1:20 ` Dave Chinner
2012-06-18 21:11 ` Eric Sandeen
2012-06-18 21:16 ` Eric Sandeen [this message]
2012-06-19 1:27 ` Dave Chinner
2012-06-19 1:11 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FDF9A9C.6060408@sandeen.net \
--to=sandeen@sandeen.net \
--cc=adilger@dilger.ca \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox