Re: Blocking vcache_tryvget() across VOP_INACTIVE() - unneeded

[Andrew Doran <ad%netbsd.org@localhost>]

On Tue, Jan 21, 2020 at 05:30:55PM -0500, Thor Lancelot Simon wrote:

> I think there's probably a generic bucket-locked hashtable implementation
> in one of the code contributions Coyote Point made long ago.  That said,
> we're talking about a screenful of code, so it's not like it'd be hard to
> rewrite, either.  Do we want such a thing?  Or do we want to press on
> towards more modern "that didn't work, try again" approaches like
> pserialize or the COW scheme you describe?

The way I see it, the original idea of the namecache was to have a thing
that allowed you avoid doing expensive hardware and file system stuff a
second time, because you'd already done it once before.  In this context
MP locking also looks a lot like expensive hardware and file system stuff.

Making the namecache's index per-directory matches the pattern in which the
data is accessed and hey presto all of a sudden there are no big concurrency
problems, any locking or whatever becomes trivial and follows the pattern of
access closely, things like pserialize/RCU start to look feasible, and one
can get back to the important business of avoiding expensive work instead of
generating it!  That's my thinking on it anyway.

The rbtrees are just what we have at hand.  I think a dynamically sized
hash, like a Robin Hood hash looks very interesting though, because we can
afford to resize occasionally on entry/removal, and modern pipelined CPUs
are great at that kind of thing.  I'm sure other people have better ideas
than I do here, though.  I just want to try out the directory approach, and
if it works well, get the basis in place.

Andrew