cvs commit: src/sys/sys buf.h src/sys/kern vfs_bio.cvfs_cluster.c src/sys/ufs/ffs ffs_softdep.c

Jeff Roberson jroberson at chesapeake.net
Thu Aug 28 00:00:53 PDT 2003


I need to go over softdep again and review the VI usage.  I know it isn't
complete.  Other than that, I don't know of any remaining buffer cache
code which needs to be locked.  If you do, let me know.

There is a lot of clean up that could be done.  The BX flags should be
moved to the B_ and BV_ flags where appropriate.  We can get rid of that
member entirely.  It was only there due to overflow of b_flags which has
lost some weight.  Also, we acquire and drop the interlock repeatedly in
some code sequences.  It will take some great effort, but some of this
could be reduced.  Also, there are some cases where a trylock might be
appropriate.

I encourage anyone that has a solid understanding of the buffer cache SMP
locking issues to please review the locking of the buf cache.  I suspect
that we can start moving giant out after I fix the locking in softupdates.

On Wed, 27 Aug 2003, Jeff Roberson wrote:

> jeff        2003/08/27 23:55:18 PDT
>
>   FreeBSD src repository
>
>   Modified files:
>     sys/sys              buf.h
>     sys/kern             vfs_bio.c vfs_cluster.c
>     sys/ufs/ffs          ffs_softdep.c
>   Log:
>    - Move BX_BKGRDWAIT and BX_BKGRDINPROG to BV_ and the b_vflags field.
>    - Surround all accesses of the BKGRD{WAIT,INPROG} flags with the vnode
>      interlock.
>    - Don't use the B_LOCKED flag and QUEUE_LOCKED for background write
>      buffers.  Check for the BKGRDINPROG flag before recycling or throwing
>      away a buffer.  We do this instead because it is not safe for us to move
>      the original buffer to a new queue from the callback on the background
>      write buffer.
>    - Remove the B_LOCKED flag and the locked buffer queue.  They are no longer
>      used.
>    - The vnode interlock is used around checks for BKGRDINPROG where it may
>      not be strictly necessary.  If we hold the buf lock the a back-ground
>      write will not be started without our knowledge, one may only be
>      completed while we're not looking.  Rather than remove the code, Document
>      two of the places where this extra locking is done.  A pass should be
>      done to verify and minimize the locking later.
>
>   Revision  Changes    Path
>   1.398     +78 -73    src/sys/kern/vfs_bio.c
>   1.143     +11 -7     src/sys/kern/vfs_cluster.c
>   1.155     +8 -5      src/sys/sys/buf.h
>   1.140     +20 -12    src/sys/ufs/ffs/ffs_softdep.c
>



More information about the cvs-src mailing list