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