Improve comments.

Submitted by:	bde
MFC after:	2 weeks

2 files changed, 7 insertions, 7 deletions

diff --git a/sys/amd64/include/atomic.h b/sys/amd64/include/atomic.h
index 30f594c..33d79b2 100644
--- a/sys/amd64/include/atomic.h
+++ b/sys/amd64/include/atomic.h
@@ -272,10 +272,10 @@ atomic_testandset_long(volatile u_long *p, u_int v)
  * addresses, so we need a Store/Load barrier for sequentially
  * consistent fences in SMP kernels.  We use "lock addl $0,mem" for a
  * Store/Load barrier, as recommended by the AMD Software Optimization
- * Guide, and not mfence.  In the kernel, we use a private per-cpu
- * cache line as the target for the locked addition, to avoid
- * introducing false data dependencies.  In user space, we use a word
- * in the stack's red zone (-8(%rsp)).
+ * Guide, and not mfence.  To avoid false data dependencies, we use a
+ * special address for "mem".  In the kernel, we use a private per-cpu
+ * cache line.  In user space, we use a word in the stack's red zone
+ * (-8(%rsp)).
  *
  * For UP kernels, however, the memory of the single processor is
  * always consistent, so we only need to stop the compiler from
diff --git a/sys/i386/include/atomic.h b/sys/i386/include/atomic.h
index 15742a5..3242d76 100644
--- a/sys/i386/include/atomic.h
+++ b/sys/i386/include/atomic.h
@@ -259,9 +259,9 @@ atomic_testandset_int(volatile u_int *p, u_int v)
  * consistent fences in SMP kernels.  We use "lock addl $0,mem" for a
  * Store/Load barrier, as recommended by the AMD Software Optimization
  * Guide, and not mfence.  In the kernel, we use a private per-cpu
- * cache line as the target for the locked addition, to avoid
- * introducing false data dependencies.  In userspace, a word at the
- * top of the stack is utilized.
+ * cache line for "mem", to avoid introducing false data
+ * dependencies.  In user space, we use the word at the top of the
+ * stack.
  *
  * For UP kernels, however, the memory of the single processor is
  * always consistent, so we only need to stop the compiler from