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, May 10, 5:00 AM
Unknown Object (File)
Feb 19 2024, 9:48 PM
Unknown Object (File)
Feb 12 2024, 4:01 PM
Unknown Object (File)
Dec 20 2023, 5:10 AM
Unknown Object (File)
Dec 9 2023, 10:48 PM
Unknown Object (File)
Oct 16 2023, 6:28 AM
Unknown Object (File)
Sep 16 2023, 7:17 PM
Unknown Object (File)
Sep 5 2023, 5:24 AM
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.