pj wrote:
> I'd expect the spinlocks to get taken
> and released in the following order on these cpusets:
>
> lock /A/B/C
> lock /A/B
> lock /A
> lock /
> ==> found what I was searching for
> unlock /
> unlock /A
> unlock /A/B
> unlock /A/B/C
The appropriate condition required to prevent deadlock is weaker than
stated above. The condition should be:
* A task can hold the spinlocks for multiple cpusets, but only
* if it acquires in bottom up order. That is, whenever a task
* tries to lock a cpuset, the only cpusets it may already have
* locked must be descendents of the one it is going for.
With this, the following sequence of lock operations would also
be acceptable, holding the bottom lock, while walking up the tree,
locking and unlocking each ancestor in turn, until one is found
that satisfies the present query. Only the bottom most lock has
to be held in this approach, for the duration.
lock /A/B/C
lock /A/B
unlock /A/B
lock /A
unlock /A
lock /
==> found what I was searching for
unlock /
unlock /A/B/C
This sequence is a little easier to implement, because there is no need
to keep a variable length queue of locks to be undone. At most two
locks are held at anytime.
If a variable length queue of locks to be undone had been needed, it
could have been implemented using one more field in each cpuset,
forming a LIFO linked list of cpusets to be unlocked.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|