Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Jul 2005 12:12:26 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j6GJCJH9001467 for ; Sat, 16 Jul 2005 12:12:21 -0700 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1Dts3U-0005Aq-00; Sat, 16 Jul 2005 21:10:32 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1Dts3Q-0001cr-OZ; Sat, 16 Jul 2005 21:10:28 +0200 Received: by kernel.dk (Postfix, from userid 1000) id C6EDD1E23C; Sat, 16 Jul 2005 21:12:17 +0200 (CEST) Date: Sat, 16 Jul 2005 21:12:17 +0200 From: Jens Axboe To: Andi Kleen Cc: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: XFS, 4K stacks, and Red Hat Message-ID: <20050716191217.GE1568@suse.de> References: <42CD4D38.1090703@xfs.org> <20050708043740.GB1679@frodo> <42D3F44B.308@strike.wu-wien.ac.at> <20050713015626.GD980@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 5654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1520 Lines: 41 On Wed, Jul 13 2005, Andi Kleen wrote: > Nathan Scott writes: > > > On Tue, Jul 12, 2005 at 06:48:11PM +0200, Alexander Bergolth wrote: > > > On 07/08/2005 06:37 AM, Nathan Scott wrote: > > > >... > > > > As other cases pop up (with a reproducible test case please, and > > > > no stacking drivers in the way too :), we slowly iron them out.. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > *cough* > > > > > I'm getting frequent stack overflows on one system, using xfs, lvm2, > > > sw-raid and libata but I don't know, if they are XFS-related. > > > > Hmmm - xfs on lvm on md on ide ...? Looks like its death by > > a thousand cuts.. thats the sort of case Steve keeps talking > > about. You will be able to crash using any filesystem doing > > this, eventually - and we haven't even got NFS in the picture > > here yet. > > Eventually even 8k stack systems might run into problems. > > A generic way to solve this would be to let the block layer > who calls into the various stacking layers check how much stack is left > first and when it is too low push the work to another thread using > a workqueue. > > Jens, do you think that would be feasible? (sorry for the late reply, vacation) Sounds like a possible solution for the problem. 4kb stack is never going to be completely enough for some block layer stacking setups. Would need some careful work, I don't want to see each and every io pushed to a worker for processing and potentially incurring 2 context switches per io. -- Jens Axboe