Re: [PATCH] cpuset semaphore depth check optimize

[Paul Jackson <pj@sgi.com>]

Robin asked:
> Can you give a _short_ explanation of why notify_on_release is
> essential? 

short - me - hah !

Ok - I'll try ;).

It's not the children, it's the parents.

Only leaf nodes in the /dev/cpuset tree can get removed,
when they have no children and no tasks.  This might
trigger walking up the parent chain, if in turn the parent
now has no children and no tasks.

Removing one or more vfs file system directories, working
from the bottom up, while in the task exit code, would have
required far more vfs locking voodoo than I can even imagine
possible.

With the usermodehelper, running rmdir(2) from a separate
thread asynchonously from userland, the only way these
directories ever get removed is via an ordinary rmdir(2)
system call, one empty directory at a time.  I trust that
the vfs file system can handle that locking; I don't even
need to know how it does it.

Let's say we have the following notify_on_release cpusets,
each with exactly one task in them:

	/dev/cpuset/A		task1
	/dev/cpuset/A/B		task2
	/dev/cpuset/A/B/C	task3

Lets further say that tasks 1, 2 and 3, exit, in that
order, task1 first.

When task1 exits, no cpusets are removed.

When task2 exits, no cpusets are removed.

When task3 exits, cpuset A/B/C needs to be removed. That in
turn triggers removing A/B.  That in turn triggers removing A.

I was confident that I could do these three removals safely
by doing three rmdir(2) system calls, one at a time, in order,
working from the bottom up.

I had no clue how to do these three removals safely, working
from the bottom up, while in the kernel exit code for task3.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401