On Thu, May 26, 2005 at 11:00:10AM +0200, Simon Derr wrote:
>
> I'm a bit concerned about this. Since there might well be
> 'notify_on_release' cpusets all over the system, and that there is only
> one cpuset_sem semaphore, I feel like this 'scaling problem' still exists
> even with:
>
> if (notify_on_release(cs)) {
> down(&cpuset_sem);
> ...
>
> Maybe adding more per-cpuset data such as a per-cpuset removal_sem might
> be worth it ?
Why not change the atomic into a lock and a refcount. Grab the lock before
each increment/decrement of the refcount and only continue with the removal
code when the refcount reaches 0. For a normal cpuset, the refcount could
be biased to 1. Then child cpusets are created, they could increment their
parent cpuset's refcount. When the notify_on_release flag used to be set,
we decrement the refcount by one. Whenever the refcount reaches 0, we
automatically remove the cpuset. Seems really clear, but would require
touching a larger chunk of the code.
Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
