Re: [PATCH] cpuset semaphore depth check optimize

[Robin Holt <holt@sgi.com>]

On Tue, Sep 20, 2005 at 07:22:55AM -0700, Paul Jackson wrote:
> Robin asked:
> 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.

This makes things even easier!!!

When you create a cpuset, set the refcount to 0.  The root
cpuset is the exception and has a refcount of 1.

When tasks are added to the cpuset, increment the refcount.

When child cpusets are created, increment the refcount.  Each
cpuset has a list of children that is protected by a single
lock.

Whenever you are decrementing the cpuset's refcount, use
atomic_dec_and_lock on the parents child list lock.  If the
notify_on_release property is set, you remove the child from
the list.

When the vfs code is traversing the list, you need to ensure
that it does not iterate unless the child list lock is held.
I have not looked at how you implemented the vfs stuff, but
that should be easily accomplished.

Where are the holes?

Thanks,
Robin
-
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/