Page MenuHomeFreeBSD

unix: Use a dedicated mtx pool for vnode name locks
ClosedPublic

Authored by jhb on Sep 26 2024, 1:22 AM.
Tags
None
Referenced Files
F102643257: D46792.diff
Fri, Nov 15, 6:13 AM
Unknown Object (File)
Thu, Nov 14, 3:21 AM
Unknown Object (File)
Sat, Nov 9, 4:24 PM
Unknown Object (File)
Sun, Nov 3, 7:12 PM
Unknown Object (File)
Sun, Nov 3, 1:20 PM
Unknown Object (File)
Tue, Oct 29, 11:42 PM
Unknown Object (File)
Oct 16 2024, 4:26 AM
Unknown Object (File)
Oct 11 2024, 4:43 PM
Subscribers

Details

Summary

mtxpool_sleep should be used as a leaf lock since it is a general
purpose pool shared across many consumers. Holding a pool lock while
acquiring other locks (e.g. the socket buffer lock in soreserve()) can
trigger LOR warnings for unrelated code.

Sponsored by: Chelsio Communications

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Sep 26 2024, 1:22 AM

The LORs I was seeing before were mitigated by rGaec2ae8b57fc638fa3ba9fac9d2067f2049ab613. However, I do think in general that locks from the global mutex pools should only be used as leaf locks.

Also, the count of 1024 locks might be too high here. I just copied the default size of the mtxpool_sleep pool. We could use a smaller value like 128 or 64 if we don't think these will be contested very often.

We definitely should go with a much lower value. The pool is used only during connect/close/detach of a named socket, which is definitely not a hot path in any sane workload.

This revision is now accepted and ready to land.Sep 30 2024, 7:04 PM

Ok, I'll drop it to 32 for commit then.