should mutexes be uniquely named?

[Konstantin Belousov]

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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"