cvs commit: src/sys/ddb db_ps.c src/sys/kern lwkt_rwlock.c lwkt_thread.c lwkt_token.c src/sys/sys globaldata.h spinlock2.h thread.h thread2.h vnode.h

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>]

dillon      2006/05/18 09:25:20 PDT

DragonFly src repository

  Modified files:
    sys/ddb              db_ps.c 
    sys/kern             lwkt_rwlock.c lwkt_thread.c lwkt_token.c 
    sys/sys              globaldata.h spinlock2.h thread.h 
                         thread2.h vnode.h 
  Log:
  Replace the LWKT token code's passive management of token ownership with
  active management based on Jeff's spin locks (which themselves are an
  adaptation of Sun spinlocks, I tihnk).
  
  LWKT tokens still have the same behavior.  That is, even though tokens now
  use a spinlock internally, they are still active only while the thread
  is running (or preempted).  When a thread non-preemptively switches away
  all held tokens are released as before and when a thread
  switches back in all held tokens are reacquired.
  
  Use spinlocks instead of tokens to manage access to LWKT RW lock structures.
  Use spinlocks instead of tokens to manage LWKT wait lists.
  
  Tokens are designed to fill a niche between spinlocks and lockmgr locks.
  Spinlocks are only to be used for short bits of low level code.  Tokens
  are designed to be used when broad serialization is desired but when the
  caller may be making calls to procedures which might block.  Lockmgr locks
  are designed to be used when strict serialization is desired even across
  blocking conditions.
  
  It should be noted that token overhead is only slightly greater than
  core spinlock overhead.  The only real difference is due to the extra
  structural management required to record the token in the thread structure
  so it can be released and reacquired.  The overhead of saving and restoring
  tokens in a thread switch is very rarely exercised (i.e. only when the
  underlying code actually blocks while holding a token).
  
  This patch reduces buildworld -j 8 times by about 5 seconds (1400->1395
  seconds on my test box), about 0.3%, but is expected to have a more
  pronounced effect as further MP work is accomplished.
  
  Revision  Changes    Path
  1.16      +1 -18     src/sys/ddb/db_ps.c
  1.9       +22 -24    src/sys/kern/lwkt_rwlock.c
  1.93      +40 -49    src/sys/kern/lwkt_thread.c
  1.24      +85 -373   src/sys/kern/lwkt_token.c
  1.41      +1 -1      src/sys/sys/globaldata.h
  1.6       +56 -10    src/sys/sys/spinlock2.h
  1.78      +12 -32    src/sys/sys/thread.h
  1.26      +1 -2      src/sys/sys/thread2.h
  1.55      +1 -0      src/sys/sys/vnode.h


http://www.dragonflybsd.org/cvsweb/src/sys/ddb/db_ps.c.diff?r1=1.15&r2=1.16&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_rwlock.c.diff?r1=1.8&r2=1.9&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_thread.c.diff?r1=1.92&r2=1.93&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_token.c.diff?r1=1.23&r2=1.24&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/globaldata.h.diff?r1=1.40&r2=1.41&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/spinlock2.h.diff?r1=1.5&r2=1.6&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/thread.h.diff?r1=1.77&r2=1.78&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/thread2.h.diff?r1=1.25&r2=1.26&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/vnode.h.diff?r1=1.54&r2=1.55&f=u