Re: Giantless VFS.

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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 
> 
>