From owner-freebsd-current@FreeBSD.ORG Mon Nov 22 12:49:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18F8E16A4CF for ; Mon, 22 Nov 2004 12:49:39 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91E1E43D6D for ; Mon, 22 Nov 2004 12:49:38 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with dspam-scanned (Exim 4.43 (FreeBSD)) id 1CWDa7-0009QD-Hq for current@freebsd.org; Mon, 22 Nov 2004 13:46:11 +0100 Received: from mailnull by anduin.net with spamassassin-scanned (Exim 4.43 (FreeBSD)) id 1CWDa3-0009Pz-V2 for current@freebsd.org; Mon, 22 Nov 2004 13:46:11 +0100 Received: from eirik.unicore.no ([213.225.74.166]) by anduin.net with esmtp (Exim 4.43 (FreeBSD)) id 1CWDa0-0009Pd-Ik; Mon, 22 Nov 2004 13:46:04 +0100 From: Eirik =?ISO-8859-1?Q?=D8verby?= To: Jeff Roberson In-Reply-To: <20041120000743.G18094@mail.chesapeake.net> References: <20041120000743.G18094@mail.chesapeake.net> Content-Type: text/plain Date: Mon, 22 Nov 2004 13:50:22 +0100 Message-Id: <1101127822.19053.13.camel@eirik.unicore.no> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on anduin.net X-Spam-Level: X-Spam-Status: No, hits=-4.7 required=7.5 tests=AWL,BAYES_00 autolearn=no version=2.64 cc: current@freebsd.org Subject: Re: Giantless VFS. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 12:49:39 -0000 On Sat, 2004-11-20 at 00:24 -0500, Jeff Roberson wrote: > I have a patch that I would like people to test and review. It's > available here: > > http://www.chesapeake.net/~jroberson/smpffs.diff > > The short description: > This patch removes Giant from the read(), write(), and fstat() syscalls, > as well as page faults, and bufdone (io interrupts) when using FFS. It > adds a considerable amount of locking to FFS and softupdates. You may > also use non ffs filesystems concurrently, but they will be protected by > Giant. If you are using quotas you should not yet run this patch. I have > done some buildworlds, but any heavy filesystem activity would be > appreciated. Hoi, what consequences can be expected from this - from a user point of view? Better performance? Better scalability? (even) More stability? New functionality? All of the above? /Eirik > Long description: > There is now a per mount-point mutex in struct ufsmount that covers ffs's > struct fs related allocation routines. The rest of the filesystem was > already covered by the buffer locks on cgs, indirs, etc, as well as a few > mutexes that were already in place. I made great attempts to minimize the > number of lock operations for the common cases which resulted in a couple > of functions which may be entered with the UFS lock held, but return > without it held. Where this is not already done, it will be documented in > comments. > > The softupdate lk lock has been turned into a mutex, and it now protects > all global worklists, inode and page dep hash buckets, etc. > interlocked_sleep() is gone now that BUF_LOCK() and msleep() take > interlock arguments. getdirtybuf() has been slightly changed to solve > some sleep related races that I disucssed with Kirk. For now there is a > single softupdates mutex, but eventually it will be made per-mountpoint > and potentially merged with the ufsmount lock. > > On the infrastructure side, the buffer cache was locked some time ago, and > now the vm is safe to run without Giant, so there are simply a lot of > removed GIANT_REQUIRED lines. I added some locking to vn_start_write() > and friends, and made some changes for LORs there. There is a pair of new > macros called VFS_(UN)LOCK_GIANT(mp) which inspects a new flag on the > mount-point to determine if we have to acquire giant. This is done very > early in the syscall path before we call any VOPs. The mountpoints should > be safe to inspect as we always own a reference to the vnode in the cases > that I have unwound for now. > > Cheers, > Jeff > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > >