ltning at anduin.net
Mon Nov 22 04:49:39 PST 2004
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:
> 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
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?
> 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
> 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.
> freebsd-current at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current