Tate, Hongliang Tian

@grief8 After fixing the two minor issues raised above, the PR will be ready to get merged.

#721 has refactored the interface of `WaitQueue`. You need to adapt this PR to the new interface.

> Perhaps it's time to consider removing the `vmo` mechanism. Agree, but we need a proposal for an alternative. > If the scheduling system continues to rely on this mechanism...

@LclclcdIsACat Could you rebase this PR to the latest main so that we can be certain that it can pass the CI?

@LclclcdIsACat Just fix the minor doc issue and fix the conflicts. And then we should be good.

> Optimizations in this way are only 10% slower on average than optimizations based on a zero-page I think keeping a zero page would be useful in more use cases....

Good to see that we have reached an consensus 😄

@lrh2000 Thanks for filing this bug. @StevenJiang1110 Could you dig into this bug?

@junyang-zh It looks like this PR needs to be rebased to the latest main branch in order to pass the CI.

@junyang-zh This is a reasonable feature for our lock implementation. But the solution is not as elegant as I thought it could be. ```rust impl