[PATCH] kernel/cpuset.c mutex conversion comment fix

The conversion of kernel/cpuset from semaphores to mutexes
missed some comments - thanks to Joe Perches for reporting this.

I didn't know offhand the state of read-write mutexes, so just
removed the hypothetical comment involving read-write semaphores,
rather than investigate how to reword it.

Signed-off-by: Paul Jackson <pj@xxxxxxx>

---

This goes on top of [PATCH v2] kernel/cpuset.c, mutex conversion.

kernel/cpuset.c | 20 +++++++-------------
1 files changed, 7 insertions(+), 13 deletions(-)

--- 2.6.15-mm2.orig/kernel/cpuset.c 2006-01-12 07:53:37.345145712 -0800
+++ 2.6.15-mm2/kernel/cpuset.c 2006-01-12 09:44:38.065160378 -0800
@@ -168,12 +168,12 @@ static struct vfsmount *cpuset_mount;
static struct super_block *cpuset_sb;

/*
- * We have two global cpuset semaphores below. They can nest.
+ * We have two global cpuset mutexes below. They can nest.
* It is ok to first take manage_mutex, then nest callback_mutex. We also
* require taking task_lock() when dereferencing a tasks cpuset pointer.
* See "The task_lock() exception", at the end of this comment.
*
- * A task must hold both semaphores to modify cpusets. If a task
+ * A task must hold both mutexes to modify cpusets. If a task
* holds manage_mutex, then it blocks others wanting that mutex,
* ensuring that it is the only task able to also acquire callback_mutex
* and be able to modify cpusets. It can perform various checks on
@@ -197,7 +197,7 @@ static struct super_block *cpuset_sb;
* Any task can increment and decrement the count field without lock.
* So in general, code holding manage_mutex or callback_mutex can't rely
* on the count field not changing. However, if the count goes to
- * zero, then only attach_task(), which holds both semaphores, can
+ * zero, then only attach_task(), which holds both mutexes, can
* increment it again. Because a count of zero means that no tasks
* are currently attached, therefore there is no way a task attached
* to that cpuset can fork (the other way to increment the count).
@@ -205,13 +205,7 @@ static struct super_block *cpuset_sb;
* if the count is zero, it will stay zero. Similarly, if a task
* holds manage_mutex or callback_mutex on a cpuset with zero count, it
* knows that the cpuset won't be removed, as cpuset_rmdir() needs
- * both of those semaphores.
- *
- * A possible optimization to improve parallelism would be to make
- * callback_mutex a R/W mutex (rwsem), allowing the callback routines
- * to proceed in parallel, with read access, until the holder of
- * manage_mutex needed to take this rwsem for exclusive write access
- * and modify some cpusets.
+ * both of those mutexes.
*
* The cpuset_common_file_write handler for operations that modify
* the cpuset hierarchy holds manage_mutex across the entire operation,
@@ -242,7 +236,7 @@ static struct super_block *cpuset_sb;
*
* The need for this exception arises from the action of attach_task(),
* which overwrites one tasks cpuset pointer with another. It does
- * so using both semaphores, however there are several performance
+ * so using both mutexes, however there are several performance
* critical places that need to reference task->cpuset without the
* expense of grabbing a system global mutex. Therefore except as
* noted below, when dereferencing or, as in attach_task(), modifying
@@ -1598,7 +1592,7 @@ static int pid_array_to_buf(char *buf, i
* Handle an open on 'tasks' file. Prepare a buffer listing the
* process id's of tasks currently attached to the cpuset being opened.
*
- * Does not require any specific cpuset semaphores, and does not take any.
+ * Does not require any specific cpuset mutexes, and does not take any.
*/
static int cpuset_tasks_open(struct inode *unused, struct file *file)
{
@@ -1972,7 +1966,7 @@ void cpuset_fork(struct task_struct *chi
*
* This routine has to take manage_mutex, not callback_mutex, because
* it is holding that mutex while calling check_for_release(),
- * which calls kmalloc(), so can't be called holding callback__sem().
+ * which calls kmalloc(), so can't be called holding callback_mutex().
*
* We don't need to task_lock() this reference to tsk->cpuset,
* because tsk is already marked PF_EXITING, so attach_task() won't

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

Relevant Pages

  • [PATCH] Update comments in cpuset.c
    ... struct cgroup_subsys cpuset_subsys; ... the cpuset they're using changes generation. ... + * There are two global mutexes guarding cpuset structures. ... Because a count of zero means that no tasks ...
    (Linux-Kernel)
  • Re: help w/ mutex
    ... Mutexes are not any faster than semaphores, as they both involve switch to ... > thread-dependant, they are merely count down dependant. ... a CriticalSection is probably what you ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch
    ... don't forget to compare this with our existing semaphore ... this means that mutexes will be _FAR MORE EXPENSIVE_ on ARM ... We'd be far better off sticking to semaphores ...
    (Linux-Kernel)
  • Re: [PATCH] use spinlock instead of binary mutex in idt77252 driver
    ... defined (I don't know what current kernels do), ... You need to verify the headerfiles for the above. ... Does this work with mutexes? ... New code should not use semaphores, ...
    (Linux-Kernel)
  • Re: help w/ mutex
    ... > Microsoft claims Mutexes are quicker, ... > Semaphores are non binary, they are based on a count-down, you can ... A semaphore can block a high priority thread ... the high priority thread to that of the lower priority thread. ...
    (microsoft.public.win32.programmer.kernel)