Date: Sat, 28 Nov 2015 16:26:04 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: should mutexes be uniquely named? Message-ID: <20151128142604.GW3448@kib.kiev.ua> In-Reply-To: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca> References: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 28, 2015 at 08:29:55AM -0500, Rick Macklem wrote: > Hi, > > I think the patches I posted last week that add "-manage-gids" are about > ready for a commit to head. > > However, there is one place in the code where I'm not sure which is better > to do: > --> The code replaces a single mutex with one for each hash list head (table > entry). > I currently use MTX_DUPOK and call them all the same thing. > or > I could add a "lockname" field to the hash table enty structure and give > each one a unique name (similar to what Garrett Wollman did in the kernel rpc). > The only downside to this is 16bytes of storage for each hash table entry. > (Admittedly, I don't think many sites would need to set the hash table size > greater than a few thousand, so this isn't a lot of malloc()'d memory.) Question is, why do you need to acquire two mutexes simultaneously ? If mutexes protect the hash list rooted in head, then this is somewhat unusual. Downside is not only the name, but also a witness overhead in the non-production kernels. > > So, what do you think. Should I add the code to make the mutex names unique? > > Thanks in advance for any comments, rick > ps: The coding change is trivial. It just involves using more malloc()'d memory. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151128142604.GW3448>