Update comments in cpuset.c
Some of the comments in kernel/cpuset.c were stale following the

transition to control groups; this patch updates them to more closely

match reality.
Signed-off-by: Paul Menage <menage@google.com>

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

 kernel/cpuset.c |  128 ++++++++++++++++++--------------------------------------

 1 file changed, 43 insertions(+), 85 deletions(-)
Index: linux-2.6.24-rc6-mm1/kernel/cpuset.c

===================================================================

--- linux-2.6.24-rc6-mm1.orig/kernel/cpuset.c

+++ linux-2.6.24-rc6-mm1/kernel/cpuset.c

@@ -64,7 +64,7 @@

  */

 int number_of_cpusets __read_mostly;
-/* Retrieve the cpuset from a cgroup */

+/* Forward declare cgroup structures */

 struct cgroup_subsys cpuset_subsys;

 struct cpuset;
@@ -160,17 +160,17 @@ static inline int is_spread_slab(const s

  * number, and avoid having to lock and reload mems_allowed unless

  * the cpuset they're using changes generation.

  *

- * A single, global generation is needed because attach_task() could

+ * A single, global generation is needed because cpuset_attach_task() could

  * reattach a task to a different cpuset, which must not have its

  * generation numbers aliased with those of that tasks previous cpuset.

  *

  * Generations are needed for mems_allowed because one task cannot

- * modify anothers memory placement.  So we must enable every task,

+ * modify another's memory placement.  So we must enable every task,

  * on every visit to __alloc_pages(), to efficiently check whether

  * its current->cpuset->mems_allowed has changed, requiring an update

  * of its current->mems_allowed.

  *

- * Since cpuset_mems_generation is guarded by manage_mutex,

+ * Since writes to cpuset_mems_generation are guarded by the cgroup lock

  * there is no need to mark it atomic.

  */

 static int cpuset_mems_generation;

@@ -182,17 +182,20 @@ static struct cpuset top_cpuset = {

 };
 /*

- * We have two global cpuset mut...
[ message continues ]