Change Details

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 this 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.

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.

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 thisese 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.