Date: Sat, 28 Nov 2015 16:40:44 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: should mutexes be uniquely named? Message-ID: <1688684587.110043576.1448746844037.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151128142604.GW3448@kib.kiev.ua> References: <2132881382.109600978.1448717395325.JavaMail.zimbra@uoguelph.ca> <20151128142604.GW3448@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik wrote: > 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. > There are two hash tables, one hashed on names and the other uid/gid. The entries are linked into both of these lists. I suppose that I could use a different name for the "name" hash table entries vs the "uid/gid" ones, which would avoid the duplication for the common cases. There are also a couple of infrequent cases (when new entries are being added to the cache) where, to avoid a LOR in mutex locking the above 2 hash tables, the code locks all the table entries in the one hash table before doing the other hash table. In this case, you will still end up with duplicates unless each lock is uniquely named. Maybe I should use a different name for the "user/group name" hash table than the "uid/gid" one, but still allow duplicates for the infrequent cases? Thanks for any help, rick > 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?1688684587.110043576.1448746844037.JavaMail.zimbra>