From owner-cvs-src@FreeBSD.ORG Tue Aug 26 00:44:48 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21C4516A4BF; Tue, 26 Aug 2003 00:44:48 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3451343FFB; Tue, 26 Aug 2003 00:44:46 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA12502; Tue, 26 Aug 2003 17:44:41 +1000 Date: Tue, 26 Aug 2003 17:44:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar In-Reply-To: <200308250139.h7P1dlwg002331@repoman.freebsd.org> Message-ID: <20030826172816.E9176@gamplex.bde.org> References: <200308250139.h7P1dlwg002331@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/gnu/ext2fs ext2_bitops.hext2_linux_balloc.c ext2_linux_ialloc.c ia64-bitops.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2003 07:44:48 -0000 On Sun, 24 Aug 2003, Marcel Moolenaar wrote: > marcel 2003/08/24 18:39:47 PDT > > FreeBSD src repository > > Modified files: > sys/gnu/ext2fs ext2_linux_balloc.c ext2_linux_ialloc.c > Added files: > sys/gnu/ext2fs ext2_bitops.h > Removed files: > sys/gnu/ext2fs ia64-bitops.h > Log: > Change of plans: Add ext2_bitops.h with generic and portable > implementations. Use those on platforms that don't have MD > headers. Remove the ia64 MD header. We're going to use the C > implementation there. > > Suggested by: bde Thnaks. I'll deventually do some benchmarks to see if we want the MD (inline assembler) versions at all. Technical questions: - Do you really need the locking (atomic_cmpset)? I think there should be higher level locking in the context of ext2fs. - The sparc64 versions seem to show need for complications in endian mismatch cases. I think ext2fs is always little endian. For bitmaps, getting a free bit from the wrong end might only be a pessizimation. ext2fs under FreeBSD has pessimized block allocation anyway. The allocator most ignores the groups and finds the next free block at the beginning of the disk, so it gives very good locality if everything fits in the first group but tends to gives fragmented allocation when the disk fills up. Bruce