[LU-6181] Fix lock contention discovery to disable extend lock growth

• Status: Closed
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Richard Henwood (Inactive)
• Assignee: Patrick Farrell (Inactive)
• Resolution: Won't Do
• Severity: 3

Issue Links

• is related to: LU-6179 Lock ahead - Request extent locks fro...

Comments

[Andreas Dilger]

Patrick, would you be able to work on a patch to fix the two-client lock contention case? I suspect something as simple as tracking when the lock was last conflicted and reducing lock growth would be beneficial.

[Patrick Farrell (Inactive)]

Sure. My focus, for now, is on LU-6179 (which needs updating to cover several things I've fixed anyway), but I think I'll have time to look in to this. (Including, critically, the performance implications.)

More to come later.

[Patrick Farrell (Inactive)]

This is old, but I just noticed it again.

At the time, I thought the lock ping-pong issue could be improved significantly with this change.  Further exploration showed that's wrong.

That belief was based on the assumption that most of the time lost was spent waiting for the other client to give up its lock.  This is not entirely true.

In the case of strided I/O, if you reduce the extent of granted locks, now you have to request a lock for every I/O, whereas even if you are ping-ponging larger locks, you can do > 1 I/O per lock.  It turns out requesting a lock for every I/O - we did actually benchmark this - is just as bad (if not slightly worse) than the original ping-pong problem.

So, nothing to do here and I'll close this one out.