lkml.org 
[lkml]   [2010]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 11/18] fs: Introduce per-bucket inode hash locks
On Sat, Oct 16, 2010 at 08:45:15PM -0400, Christoph Hellwig wrote:
> On Sun, Oct 17, 2010 at 04:12:13AM +1100, Nick Piggin wrote:
> > > With the changes Dave implemented based on my suggestions we now have
> > > an abstract locked hash list data type. It has the normal hash list
> > > operations plus lock/unlock operations.
> >
> > That's ugly. It just hides the locking. If a bit of casting bothers
> > you then put it in a function where it is used like I did.
>
> Exposing the implementation details of which bit of a pointer can
> be used as lock when cast to an unsigned long to every user of an
> abstract type is what I would consider ugly, and on similar issues
> I've certainly not been the only one.

The low bit.


> > > So if e.g. the -rt folks need
> > > real locks in there there is one single place they need to touch
> > > instead of every user. Similarly if we want to add lockdep support
> > > there is just one place to touch.
> >
> > It's unnecessary.
>
> What, lockdep support?

Yes. It would be stupid to do lockdep support for bit spinlocks in all
places where they are used. What should be done (and there is work
towards) is to be able to change the bit spinlock API (or add a new one)
so that external lockdep data structure can be given.



\
 
 \ /
  Last update: 2010-10-17 04:09    [W:0.128 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site