https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6181 Lustre LU-6181

Fix lock contention discovery to disable extend lock growth

Bug Minor Closed Won't Do Patrick Farrell Richard Henwood Thu, 29 Jan 2015 23:04:38 +0000 Tue, 13 Nov 2018 22:38:22 +0000 Tue, 13 Nov 2018 22:38:22 +0000 0 6 <p>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.</p> <p>Sure. My focus, for now, is on <a href="https://jira.whamcloud.com/browse/LU-6179" title="Lock ahead - Request extent locks from userspace" class="issue-link" data-issue-key="LU-6179"><del>LU-6179</del></a> (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.)</p> <p>More to come later.</p> <p>This is old, but I just noticed it again.</p> <p>At the time, I thought the lock ping-pong issue could be improved significantly with this change.  Further exploration showed that's wrong.</p> <p>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.</p> <p>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 &gt; 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.</p> <p>So, nothing to do here and I'll close this one out.</p> Related LU-6179 Development Rank 1|hzx59b: Rank (Obsolete) 17293 Severity