Page MenuHomeFreeBSD

rmlock: Add required compiler barriers to _rm_runlock()
ClosedPublic

Authored by markj on Feb 25 2022, 9:10 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 10, 10:58 PM
Unknown Object (File)
Fri, Oct 10, 9:16 PM
Unknown Object (File)
Mon, Sep 29, 5:11 PM
Unknown Object (File)
Fri, Sep 26, 2:59 PM
Unknown Object (File)
Sun, Sep 21, 4:11 PM
Unknown Object (File)
Sep 9 2025, 2:04 AM
Unknown Object (File)
Aug 3 2025, 5:23 AM
Unknown Object (File)
Aug 2 2025, 10:37 PM
Subscribers

Details

Summary

Also remove excessive whitespace in _rm_rlock().

Diff Detail

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

Event Timeline

markj requested review of this revision.Feb 25 2022, 9:10 PM
This revision is now accepted and ready to land.Feb 25 2022, 9:29 PM
sys/kern/kern_rmlock.c
516

Why not just use critical_enter()/critical_exit() here? Are we in a spot where the pending preemption check in critical_exit() can't be tolerated?

sys/kern/kern_rmlock.c
516

See the if statement below, preemption check is merged with another one to save a branch.

sys/kern/kern_rmlock.c
516

Another reason is that critical_enter()/_exit() were historically not inline functions; that changed only in the past few years. So we could certainly use critical_enter() here, but switching to critical_exit() in _rm_rlock() results in worse-looking code: https://reviews.freebsd.org/P540
In particular, the patched version uses many callee-saved registers.

I suspect it's worth keeping this micro-optimization. I guess we could at least use critical_enter(), but that on its own doesn't represent much of an improvement to me.

sys/kern/kern_rmlock.c
516

I have to note critical_exit is already suboptimal by having to test for preemption using a different variable. Instead, both preemption and the flag could be in one int (if not short). It does not even have to be per-thread, rather can be moved per-CPU. I don't know how feasible it is outside of amd64 though.