test hash functions for fsid
rmacklem at uoguelph.ca
Thu May 9 15:41:19 UTC 2019
Conrad Meyer wrote:
[good stuff snipped]
>Usually it makes sense to size hash tables for the size of the data;
>for direct insert tables you want to keep the load factor below 0.8 or
>something like that. So the hardcoded 256 doesn't make a ton of
I took a closer look at the code and I think I can delay use of the hash tables until
after getmntinfo() returns the number of file systems, with a little tweaking.
Since Peter already has a server with over 72000 file systems, setting it dynamically
seems worth doing.
I didn't understand what you meant by load factor below 0.8, but how does
num / 20 (where "num" is the number of file systems->entries to be hashed)
sound for the size of the tables. (There would be one table now and a second one
allocated for the patch that does updated changes to the kernel, for a total of two
of them malloc()d when the daemon starts up. The tables are just SLIST_HEAD()s
or one pointer per table entry.
Btw, I will post Peter's test results if he says that's ok, but the first three hashes
work about equally well. For his big 72532 file system server and H1 (which
seems to be the winner by a small fraction):
Ave variation about the mean: 13 (or less than 5%)
[more good stuff snipped]
More information about the freebsd-fs