Vladimir V. Saveliev writes:
> Hello
>
> Christoph Hellwig wrote:
> > ...
> > Looking at the actual code all these point to the spin lock obsufcation
> > SPIN_LOCK_FUNCTIONS/RW_LOCK_FUNCTIONS from spin_macros.h which I told
> > to get rid of in the first round of reviews.
> > ...
>
> reiser4 spinlock macros provide following functionality:
>
> (1) encapsulation of locks: instead of writing spin_lock(&obj->lock),
> where obj is object of type foo, one writes spin_lock_foo(obj).
>
> (2) keeping information about number of locks of particular type currently
> held by thread
>
> (3) checking that locks are acquired in the proper order.
>
> (4) collection of spin lock contention statistics
>
>
> I agree that (1) is not very necessary. (2) and (4) helped a lot in early
> debugging. Now we are about to remove it.
This was already discussed during earlier attempts to merge reiser4. The
proper solution purportedly is to make useful features of reiser4
spin-lock code generic and merge them so that the rest of kernel can
enjoy their superiority.
>
> However, we would prefer to keep (3). It makes catching spinlock deadlocks very
> easy. Don't you think that makes sence?
Lock-ordering monitoring was _immensely_ useful. For one thing it forces
one to have complete and up to date description of lock ordering.
>
> Thanks
Nikita.
-
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]
| |
 |