cvs commit: src/sys/i386/i386 mp_machdep.c src/sys/i386/include cpufunc.h src/sys/kern kern_clock.c kern_timeout.c kern_umtx.c lwkt_ipiq.c lwkt_msgport.c lwkt_thread.c lwkt_token.c vfs_journal.c src/sys/sys thread2.h

[Matthew Dillon]

dillon      2005/06/03 16:57:34 PDT

DragonFly src repository

  Modified files:
    sys/i386/i386        mp_machdep.c 
    sys/i386/include     cpufunc.h 
    sys/kern             kern_clock.c kern_timeout.c kern_umtx.c 
                         lwkt_ipiq.c lwkt_msgport.c lwkt_thread.c 
                         lwkt_token.c vfs_journal.c 
    sys/sys              thread2.h 
  Log:
  Replace cpu_mb1() and cpu_mb2() with cpu_mfence(), cpu_lfence(), cpu_sfence(),
  and cpu_ccfence().  These provide memory and compiler fences to guarentee
  read/write ordering of memory and to prevent the compiler itself from
  generating reordered code in particular cases.
  
  Most of the cases where care must be taken are tail-chasing FIFO cases,
  especially in the IPI messaging code.
  
  At the moment on SMP boxes we use a locked bus cycle on (%%esp) for the
  lfence and mfence.  The only other choices are to use a cpuid instruction
  or one of the {S,L,M}FENCE instructions.  cpuid is usually horrible, and
  the *FENCE instructions do not exist on older cpus.
  
  Linux seems to use the locked bus cycle or *FENCE instruction method.
  
  Although I have no conclusive evidence, a number of crash dumps provided
  by David Rhodus has led me to believe that speculative reads by modern cpus,
  in particular in HTT situations with Intel cpus, can survive many more
  instructions then previously believed.  The only safe solution is to use
  an instruction sequence which guarentees proper operation.
  
  I would prefer to avoid the use of a locked bus cycle but at least in the
  IPIQ case (the most common case we have to worry about), only one locked
  bus cycle is required and then the entire IPIQ can be processed without
  further locked cycles.
  
  Revision  Changes    Path
  1.36      +6 -5      src/sys/i386/i386/mp_machdep.c
  1.13      +52 -3     src/sys/i386/include/cpufunc.h
  1.42      +13 -4     src/sys/kern/kern_clock.c
  1.15      +1 -1      src/sys/kern/kern_timeout.c
  1.4       +1 -1      src/sys/kern/kern_umtx.c
  1.11      +21 -6     src/sys/kern/lwkt_ipiq.c
  1.32      +3 -2      src/sys/kern/lwkt_msgport.c
  1.74      +4 -4      src/sys/kern/lwkt_thread.c
  1.15      +5 -5      src/sys/kern/lwkt_token.c
  1.13      +6 -5      src/sys/kern/vfs_journal.c
  1.18      +2 -2      src/sys/sys/thread2.h


http://www.dragonflybsd.org/cvsweb/src/sys/i386/i386/mp_machdep.c.diff?r1=1.35&r2=1.36&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/i386/include/cpufunc.h.diff?r1=1.12&r2=1.13&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_clock.c.diff?r1=1.41&r2=1.42&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_timeout.c.diff?r1=1.14&r2=1.15&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_umtx.c.diff?r1=1.3&r2=1.4&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_ipiq.c.diff?r1=1.10&r2=1.11&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_msgport.c.diff?r1=1.31&r2=1.32&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_thread.c.diff?r1=1.73&r2=1.74&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_token.c.diff?r1=1.14&r2=1.15&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/kern/vfs_journal.c.diff?r1=1.12&r2=1.13&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/sys/thread2.h.diff?r1=1.17&r2=1.18&f=u