[PATCH] Cpuset: rcu slab cache optimization rcu_dereference comment

[Paul Jackson <pj@sgi.com>]

Add a comment noting that unlike usual, we do not need to
guard a dereference of an rcu guarded pointer with a
call to rcu_dereference(), because we don't care if we
see out of order results.

Signed-off-by: Paul Jackson <pj@sgi.com>

---

 kernel/cpuset.c |    6 ++++++
 1 files changed, 6 insertions(+)

--- 2.6.15-rc3-mm1.orig/kernel/cpuset.c	2005-12-11 22:35:39.051718313 -0800
+++ 2.6.15-rc3-mm1/kernel/cpuset.c	2005-12-12 00:38:25.301117045 -0800
@@ -632,6 +632,12 @@ static void guarantee_online_mems(const 
  * unmapped.  It's ok if attach_task() replaces our cpuset with
  * another while we are reading mems_generation, and even frees it.
  *
+ * We do -not- need to guard the 'cs' pointer dereference within the
+ * rcu_read_lock section with rcu_dereference(), because we don't
+ * mind getting bogus out-of-order results.  New cpuset pointer and
+ * old mems_generation is ok - we'll realize that our cpuset memory
+ * placement changed the next time through here.
+ *
  * This routine is needed to update the per-task mems_allowed data,
  * within the tasks context, when it is trying to allocate memory
  * (in various mm/mempolicy.c routines) and notices that some other

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/