Both of these features are not needed by many consumers and result in avoidable reads which in turn puts them on profiles due to cache-line ping ponging.
On top of that the current lockgmr entry point is slower than necessary single-threaded. As an attempted clean up preparing for other changes, provide new routines which don't support any of the aforementioned features.
With these patches in place vop_stdlock and vop_stdunlock disappear from flamegraphs during -j 104 buildkernel.
I don't have a strong opinion about naming of vop_ routines. Part of longer term idea is to provide explicit VOP_XLOCK and VOP_SLOCK routines so that the code does not have to branch on the request. Filesystems which don't support shared locking can just set both to the same routine. Finally, if the code followed that it e.g., VOP_SLOCKed, it can VOP_SUNLOCK. In the current state it wont make a difference, but it will open up possiblity of doing lock xadd on the lock word without reading from it earlier (and in turn increase scalability). Once more filesystems which don't support shared locking can set this to the same routine which would be used for VOP_XUNLOCK.