Re: [PATCH 3/3] fs: rcu protect inode hash lookups

[Eric Dumazet <eric.dumazet@gmail.com>]

Le mardi 02 novembre 2010 à 11:01 +1100, Dave Chinner a écrit :

> So, to go to per-chain locks as per the proposed bit-lock-on-the-
> low-bit-of-the-head-pointer infrastructure, we'll have to cross that
> with the hlist_null code that plays low-bit pointer games for
> detecting the end of the chain.
> 

So what, just use another bit for the lock, this still let 30 bit for
the nulls value (62 bits on 64bit arches). Anyway, the bit lock is
rejected by RT guys, so why do you still care ?


> The chain is determined by hashing the inode number. Perhaps a
> simple enough test is to hash the last inode number on a cache miss
> and if that doesn't match the hash of the lookup key we redo the
> search. That seems to me like it will avoid needing to play games
> with termination markers - does that sound reasonable?
> 

Sure, if only the inode number is the key, it can be fetched in atomic
way so it should be good, even without taking a stable reference on last
item. It could be a problem if i_ino becomes a larger field...

Note : you'll have to remember the last item i_ino in a variable, not to
refetch it from a 'last item' pointer (this last item could also change
its chain...)

For TCP, hash key is a complex hash function of many fields needing to
take a reference before computing it, this was not an option.