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

[Mateusz Guzik <mjguzik%gmail.com@localhost>]

On 1/22/20, Andrew Doran <ad%netbsd.org@localhost> wrote:
> 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.
>

But a hash which has collisions taken care of with linked lists is the
easiest data structure to scale in this regard. Additions and removals
in the face of concurrent lookups are easy to handle (and in fact the
current code already does it to some extent).

With no safe memory reclamation in use this still provides a win as
contetnion is spread out across different buckets.

-- 
Mateusz Guzik <mjguzik gmail.com>