+++ This bug was initially created as a clone of Bug #235697 +++ To solve the performance problems seen with the alternate test and similar contention cases, we need to implement some kind of minimum lock hold time to ensure that the cluster makes progress even in heavy lock traffic. Probably we need a user configurable, but with a sensible default, setting which puts a maximum cap on the minimum lock hold time, and then try to set the lock hold time automatically using information gathered from the system, such as how long the wait has been when acquiring the lock, how much work needs to be done, etc.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This has missed 5.1, so retarget for 5.2?
*** This bug has been marked as a duplicate of 248480 ***