From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Sandeen Subject: Re: XFS status update for May 2012 Date: Mon, 18 Jun 2012 16:16:12 -0500 Message-ID: <4FDF9A9C.6060408@sandeen.net> References: <20120618120853.GA15480@infradead.org> <4FDF9998.6020205@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , "linux-fsdevel@vger.kernel.org Devel" , xfs@oss.sgi.com To: Andreas Dilger Return-path: Received: from sandeen.net ([63.231.237.45]:42957 "EHLO mail.sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753003Ab2FRVQO (ORCPT ); Mon, 18 Jun 2012 17:16:14 -0400 In-Reply-To: <4FDF9998.6020205@sandeen.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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