Date: Thu, 9 May 2019 15:41:15 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "cem@freebsd.org" <cem@freebsd.org> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@FreeBSD.org> Subject: Re: test hash functions for fsid Message-ID: <YQBPR0101MB22609A3705C978F0434AEDE3DD330@YQBPR0101MB2260.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAG6CVpUER0ODF5mfdGFA-soSpGbh=qkjc4rKiJEdaOUaUaUmAw@mail.gmail.com> References: <YQBPR0101MB2260D82BAE348FB82902508CDD320@YQBPR0101MB2260.CANPRD01.PROD.OUTLOOK.COM>, <CAG6CVpUER0ODF5mfdGFA-soSpGbh=qkjc4rKiJEdaOUaUaUmAw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >sense, IMO. 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): Mean: 283 Ave variation about the mean: 13 (or less than 5%) [more good stuff snipped] Thanks, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB22609A3705C978F0434AEDE3DD330>