From owner-freebsd-fs@FreeBSD.ORG Tue Aug 14 07:00:31 2007 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A98A16A469; Tue, 14 Aug 2007 07:00:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 344FC13C4A8; Tue, 14 Aug 2007 07:00:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l7E70GHS006592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2007 17:00:27 +1000 Date: Tue, 14 Aug 2007 16:06:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20070810124153.GW2738@deviant.kiev.zoral.com.ua> Message-ID: <20070814154812.J24186@besplex.bde.org> References: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070712225324.F9515@besplex.bde.org> <20070712142127.GD2200@deviant.kiev.zoral.com.ua> <20070716195556.P12807@besplex.bde.org> <20070721063434.GI2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> <20070808004001.O926@besplex.bde.org> <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> <20070810133946.H769@besplex.bde.org> <20070810124153.GW2738@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bugs@FreeBSD.org, fs@FreeBSD.org Subject: Re: msdosfs not MPSAFE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 07:00:31 -0000 On Fri, 10 Aug 2007, Kostik Belousov wrote: > On Fri, Aug 10, 2007 at 01:54:48PM +1000, Bruce Evans wrote: >> I wrote yet another patch, with allocation on the stack so that no locking >> is required. This is simpler and doesn't require any new functions. >> Unfortunately, it is larger because it changes the interfaces for most >> functions. The interface changes are routine, so this is probably better. >> Note that 'struct dirent's are already allocated on the stack. This >> patch adds allocation of 'struct mbnambuf's which are slightly smaller >> (~256 bytes). I think this is just small enough for stack allocation. > > I agree that this is the best approach. The size of the on-stack > structure still make me worry, although ~270 bytes seems to be not too > large for 3-pages stack. Stack growth seems to be nowhere near a problem. With the extra ~270 bytes. ls -lR on i386 uses less than a 1-page stack (about 3.5K, including 0x270 bytes for the pcb). I think the maximum stack depth is attained when a debugger trap traps a fast interrupt interrupting a page fault in an i/o routine called from msdosfs_readdir(). Unlike in RELENG_4, nested interrupts can't occur, so a 1-page stack should be enough for everything on i386 (but of course isn't quite enough). I didn't try hard to attain the maximum depth, and just looked at where the stack got to after running a large ls -lR for a while. msdosfs_readdir() now allocates 0x2b0 bytes on the stack using "subl $0x2b0,%esp" and that is now the largest single allocation. This is without INVARIANTS etc. Bruce