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
F102572454: D34381.id103244.diff
Thu, Nov 14, 5:36 AM
Unknown Object (File)
Tue, Nov 12, 12:43 PM
Unknown Object (File)
Fri, Nov 1, 5:05 PM
Unknown Object (File)
Oct 14 2024, 5:37 AM
Unknown Object (File)
Oct 10 2024, 2:18 PM
Unknown Object (File)
Oct 10 2024, 2:18 PM
Unknown Object (File)
Oct 10 2024, 2:17 PM
Unknown Object (File)
Oct 10 2024, 2:01 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.