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-11518 Lustre <p>Mitsuhiro reported lock_count is exceeding lru_size ( disabled lru resize) on DDN es3.x branch before, and when we tested with master, found the same problem can also be seen on upstream.</p> <p> <br/>  </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> # <span class="code-keyword">for</span> i in `seq -w 10001 20000`; <span class="code-keyword">do</span> dd <span class="code-keyword">if</span>=/dev/zero of=/mnt/lustre/1KB_file-${i} bs=1K count=1 &gt; /dev/<span class="code-keyword">null</span> 2&gt;&amp;1 ; echo ${i} ; done # lctl get_param ldlm.namespaces.*.lru_size ldlm.namespaces.lustre-MDT0000-mdc-ffff8d0afcc55000.lru_size=800 ldlm.namespaces.lustre-OST0000-osc-ffff8d0afcc55000.lru_size=800 ldlm.namespaces.lustre-OST0001-osc-ffff8d0afcc55000.lru_size=800 # lctl get_param ldlm.namespaces.*.lock_count ldlm.namespaces.lustre-MDT0000-mdc-ffff8d0afcc55000.lock_count=800 ldlm.namespaces.lustre-OST0000-osc-ffff8d0afcc55000.lock_count=4090 ldlm.namespaces.lustre-OST0001-osc-ffff8d0afcc55000.lock_count=4096   </pre> </div></div> <p>{{}}</p> Client: <br/> 2.11.53_197_g0f2d3f5 <br/> Server: <br/> 2.11.53_197_g0f2d3f5 LU-11518

lock_count is exceeding lru_size

Bug Major Resolved Fixed Gu Zheng Gu Zheng LTS12 ORNL Mon, 15 Oct 2018 07:24:30 +0000 Wed, 28 Dec 2022 18:59:43 +0000 Fri, 25 Sep 2020 03:56:36 +0000 Lustre 2.14.0 0 14 <p>Gu Zheng (gzheng@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/33371" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33371</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: control lru_size for extent lock<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: c007a30dbf0ec35caddc33696c7533be098462ee</p> <p>Can you please link the LU ticket and patch that removed ELC for extent locks? While I agree this patch is good to avoid overflowin the LRU size, canceling locks with ELC avoids sending extra RPCs. I'd like to understand why ELC was turned off. </p> <p>what about <a href="https://jira.whamcloud.com/browse/LU-8209" title="glimpse lock request does not engage ELC to drop unneeded locks" class="issue-link" data-issue-key="LU-8209"><del>LU-8209</del></a> that seems to introduce ELC for every ldlm enqueue?</p> <p>I'd suggest to add some debug message in ldlm_prep_elc_req() and check wheteher it releases lock from time to time. In theory, if ldlm_prep_elc_req() releases lock as expected, LRU shouldn't grow larger than the limitation.</p> <p>Is it possible that enqueue RPC doesn't have a lot of space to save the ELC locks? For example, in a given I/O patern, maybe all the payload has already been taken and no space for ELC at all?</p> <p>Hi Oleg, Andreas</p> <p>Since <a href="https://jira.whamcloud.com/browse/LU-8209" title="glimpse lock request does not engage ELC to drop unneeded locks" class="issue-link" data-issue-key="LU-8209"><del>LU-8209</del></a> landed in 2.9, and introduce ELC for every ldlm enqueue, but when I added debug code to trace ldlm_prep_elc_req(), it works to mdc locks, but seems doesn't work to osc locks.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> [ 1203.258882] #####ldlm cli enqulock:102 [ 1203.259923] ####: avail:408, to_free:1, count:0,pack:0 &lt;--osc [ 1203.263990] ####: avail:368, to_free:1, count:1,pack:1 &lt;--mdc [ 1203.266082] #####ldlm cli enqulock:103 [ 1203.267089] ####: avail:408, to_free:1, count:0,pack:0 count += ldlm_cancel_lru_local(ns, cancels, to_free, avail - count, 0, lru_flags); </pre> </div></div> <p>lru_size is default to 100 on my testing VMs.</p> <p>So when enqueue locks over lru_size limit, we can see mdc cancel locks one by one, but osc doesn't.</p> <p>Sorry to my limited understanding, please correct me if I'm missing something.</p> <p> </p> <p>When disabled lru_resize, I traced ldlm_prep_elc_req&amp;ldlm_prepare_lru_list, found EXTENT locks are <b>skipped</b> even though lock_count already exceeded lru_size.</p> <p>That's the situation we meet above, there is no more chance for extent locks to be canceled at enqueue time. Although we can set lru_size=clear to cleanup all, but we can't be always conscious of this condition immediately.</p> <p>Gu Zheng,</p> <p>Do you know <b>why</b> they are being skipped?  It seems like we should fix that, rather than do the async stuff.</p> <p>Hi Patrick,</p> <p> </p> <p>I don't know the root cause, but according to previous debug, <b>osc_ldlm_weigh_ast</b> is not 0, means that the lock can't be early cancelled.</p> <p>Since ELC calls  <b>osc_ldlm_weigh_ast</b> -&gt; <b>weigh_cb</b> to judge wether the lock is <b>safe enough</b> to cancel early, it checks every page from ldlm_extent, if any of the page(vmpage) is Dirty, ELC will skip this lock.</p> <p>As mentioned in the summary, this condition is really common if there are explosive write I/O, ELC can't make positive effect to it.</p> <p>It would be good to get -1 trace on one of these calls to osc_ldlm_weigh_ast - I am skeptical that you actually have a dirty page under all your locks.  That is probably only possible with a workload that is dirtying many, many files with a small amount of data, very quickly.  I guess if you are creating many small files that might be possible...</p> <p>I wonder if you are actually hitting this case:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> lock_res_and_lock(dlmlock); obj = dlmlock-&gt;l_ast_data; if (obj) cl_object_get(osc2cl(obj)); unlock_res_and_lock(dlmlock); if (obj == NULL) GOTO(out, weight = 1);</pre> </div></div> <p>Because if we cannot find the OSC object, we assume we should not cancel the lock.  So if a bunch of OSC objects are being destroyed, all of their associated LDLM locks will be ignored for ELC.</p> <p>This seems incorrect to me...</p> <p>This was copied over from the old CLIO code, before Jinshan's simplification, but when we copied, we changed from 0 to 1 (which means 'keep the lock') in this case:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>- lock = osc_ast_data_get(dlmlock); - if (lock == NULL) { - /* cl_lock was destroyed because of memory pressure. - * It is much reasonable to assign this type of lock - * a lower cost. - GOTO(out, weight = 0);</pre> </div></div> <p>I'll push a patch.</p> <p>Anyway, you should be able to figure out if this patch will help just by using trace debug to check how you're exiting osc_ldlm_weigh_ast.</p> <p>You could also check your lock used vs unused counts in LDLM, that might be interesting too.</p> <p>Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/34584" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34584</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: Do ELC on locks with no OSC object<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 85b597ef9b847b94a07103601f3a25ff3367e941</p> <p>Hi Patrick,</p> <p>&gt; That is probably only possible with a workload that is dirtying many, many files with a small amount of data, very quickly.  I guess if you are creating many small files that might be possible...</p> <p>Yeah, correct, we hit this problem when creating lots of small files for testing, please see the reproduce script in the summary.</p> <p><a href="https://review.whamcloud.com/34584" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34584</a></p> <p>And I have no objections to this patch, but it doesn't help to resolve the above problem. </p> <p>Andriy Skulysh (c17819@cray.com) uploaded a new patch: <a href="https://review.whamcloud.com/35285" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35285</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ptlrpc: don't reset lru_resize on idle reconnect<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: c3735255aceecbae25574138fc139c0ccd895711</p> <p>Gu Zheng (gzheng@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/35396" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35396</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: cancel osc_lock list traversal once found the lock is being used<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 4352d6c132f2e02f2100049455131fd5a8257bbc</p> <p>Gu Zheng (gzheng@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/35397" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35397</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: restore ELC for locks that have dirty pages<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 299f8f710f18bf5c0b1263bc5792d40cb7c07bd5</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/35285/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35285/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ptlrpc: don't reset lru_resize on idle reconnect<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: acacc9d9b1d0a869f61d7940baa0700b63dcd8f7</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/35396/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35396/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: cancel osc_lock list traversal once found the lock is being used<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: eb9aa909343b95769cbf90eec36ded8821d4aa12</p> <p>Minh Diep (mdiep@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/35489" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35489</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ptlrpc: don't reset lru_resize on idle reconnect<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 876bbf289b3fb41aa6b19462da3a95257df52554</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/35489/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35489/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ptlrpc: don't reset lru_resize on idle reconnect<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: <br/> Commit: beeacfb88a443401e4421f36451fedebdfcf7cc0</p> <p>Hi <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=pfarrell" class="user-hover" rel="pfarrell">pfarrell</a> <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger" class="user-hover" rel="adilger">adilger</a><br/> Could help to have a look at the restore ELC patch (<a href="https://review.whamcloud.com/35397)?" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35397)?</a><br/> the patch itself only removes dirty page checking in weight_cb when preparing cancel list, but it introduced many fails on time out.<br/> According previous investigation, the timeout occurred when <b>fail ost</b>, I have dump the call trace when replay-ost-single test_1.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[ 1106.410531] Call Trace: [ 1106.411660] [&lt;ffffffff8d363107&gt;] dump_stack+0x19/0x1b [ 1106.413944] [&lt;ffffffffc0a1e8dc&gt;] osc_extent_wait+0x5dc/0x750 [osc] [ 1106.416400] [&lt;ffffffff8ccd6b60&gt;] ? wake_up_state+0x20/0x20 [ 1106.418593] [&lt;ffffffffc0a20b57&gt;] osc_cache_wait_range+0x2e7/0x940 [osc] [ 1106.421190] [&lt;ffffffffc0a21d7e&gt;] osc_cache_writeback_range+0xbce/0x1260 [osc] [ 1106.423971] [&lt;ffffffffc03aad98&gt;] ? libcfs_debug_msg+0x688/0xab0 [libcfs] [ 1106.426865] [&lt;ffffffffc053c4bb&gt;] ? cl_env_get+0x1bb/0x270 [obdclass] [ 1106.429221] [&lt;ffffffffc0a0dd85&gt;] osc_lock_flush+0x195/0x290 [osc] [ 1106.431463] [&lt;ffffffffc0a0e243&gt;] osc_ldlm_blocking_ast+0x2e3/0x3a0 [osc] [ 1106.433930] [&lt;ffffffffc0530001&gt;] ? lustre_fill_super+0x6b1/0x950 [obdclass] [ 1106.436432] [&lt;ffffffffc07c6b5a&gt;] ldlm_cancel_callback+0x8a/0x330 [ptlrpc] [ 1106.438807] [&lt;ffffffffc053bd30&gt;] ? cl_env_put+0x140/0x1d0 [obdclass] [ 1106.441008] [&lt;ffffffffc0a0d978&gt;] ? osc_ldlm_weigh_ast+0x118/0x390 [osc] [ 1106.443332] [&lt;ffffffffc07c6e56&gt;] ldlm_lock_cancel+0x56/0x1f0 [ptlrpc] [ 1106.445551] [&lt;ffffffffc07e2275&gt;] ldlm_cli_cancel_list_local+0x85/0x280 [ptlrpc] [ 1106.447985] [&lt;ffffffffc07e2a0b&gt;] ldlm_cancel_lru_local+0x2b/0x30 [ptlrpc] [ 1106.450215] [&lt;ffffffffc07e5797&gt;] ldlm_replay_locks+0x5c7/0x880 [ptlrpc] [ 1106.452153] [&lt;ffffffffc03a4cce&gt;] ? ktime_get_real_seconds+0xe/0x10 [libcfs] [ 1106.454474] [&lt;ffffffffc082e145&gt;] ptlrpc_import_recovery_state_machine+0x5a5/0x920 [ptlrpc] [ 1106.457066] [&lt;ffffffffc0830c91&gt;] ptlrpc_connect_interpret+0xe21/0x2150 [ptlrpc] [ 1106.459344] [&lt;ffffffffc0805921&gt;] ptlrpc_check_set.part.23+0x481/0x1e10 [ptlrpc] [ 1106.461638] [&lt;ffffffffc080730b&gt;] ptlrpc_check_set+0x5b/0xe0 [ptlrpc] [ 1106.463659] [&lt;ffffffffc08333cb&gt;] ptlrpcd_check+0x4ab/0x590 [ptlrpc] [ 1106.465622] [&lt;ffffffffc083374b&gt;] ptlrpcd+0x29b/0x550 [ptlrpc] [ 1106.467359] [&lt;ffffffff8ccd6b60&gt;] ? wake_up_state+0x20/0x20 [ 1106.469039] [&lt;ffffffffc08334b0&gt;] ? ptlrpcd_check+0x590/0x590 [ptlrpc] [ 1106.471004] [&lt;ffffffff8ccc1da1&gt;] kthread+0xd1/0xe0 [ 1106.472420] [&lt;ffffffff8ccc1cd0&gt;] ? insert_kthread_work+0x40/0x40 [ 1106.474233] [&lt;ffffffff8d375c37&gt;] ret_from_fork_nospec_begin+0x21/0x21 [ 1106.476078] [&lt;ffffffff8ccc1cd0&gt;] ? insert_kthread_work+0x40/0x40 </pre> </div></div> <p>osc_extent_wait_range is waiting dirty pages of target extent lock to be written out, but seems no one flushed them, so the thread stalled there.</p> <p>Zheng,</p> <p>Hmm.  I can try to take a look.</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=pfarrell" class="user-hover" rel="pfarrell">pfarrell</a> thanks.</p> <p>Hi <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=pfarrell" class="user-hover" rel="pfarrell">pfarrell</a> <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger" class="user-hover" rel="adilger">adilger</a><br/> Seems restoring ELC for locks that have dirty pages (similar to reverting <a href="https://jira.whamcloud.com/browse/LU-4300" title="ptlrpcd threads deadlocked in cl_lock_mutex_get" class="issue-link" data-issue-key="LU-4300"><del>LU-4300</del></a>, though not whole of it) will reintroduce the deadlock issue that <a href="https://jira.whamcloud.com/browse/LU-4300" title="ptlrpcd threads deadlocked in cl_lock_mutex_get" class="issue-link" data-issue-key="LU-4300"><del>LU-4300</del></a> fixed, that's why it repeatedly failed on regression test of timeout.<br/> I am wondering whether it's better to fallback to previous version (<a href="https://review.whamcloud.com/33371" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33371</a>) ? Invoking ldlm_cancel_lru to force cancel once the lock_count exceeded.</p> <p>I was not really against the 33371 patch as much as Oleg was. Allowing locks <b>above</b> <tt>lru_size</tt> to be cancelled in a batch of <tt>LDLM_LRU_EXCESS_LIMIT=16</tt> locks makes sense to me, for efficiency reasons. If Oleg really feels that we shouldn't exceed <tt>lru_size</tt> at all (though without this patch we can already exceed <tt>lru_size</tt> by many thousands of locks), then we could shrink a batch of locks <b>below</b> <tt>lru_size</tt>.</p> <p>Of course, even better, as Oleg and Vitaly suggest would be to fix dynamic LRU size, but as yet it isn't really working properly (AFAICS) under pressure (only via aging), and it still makes sense to fix the fixed LRU size case since there are a number of sites using this already.</p> <p>Thanks <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger" class="user-hover" rel="adilger">adilger</a><br/> Yeah, I see. Anyway, will respin patch 33371 and push it for review first.</p> <p>Vitaly Fertman (vitaly.fertman@hpe.com) uploaded a new patch: <a href="https://review.whamcloud.com/39560" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39560</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: lru code cleanup<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 42c19efb8424be3915b8e37b87578269fe523fd0</p> <p>Vitaly Fertman (vitaly.fertman@hpe.com) uploaded a new patch: <a href="https://review.whamcloud.com/39561" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39561</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: cancel LRU improvement<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 5b712dcabaee42878af613106240d9ecc286fd90</p> <p>Vitaly Fertman (vitaly.fertman@hpe.com) uploaded a new patch: <a href="https://review.whamcloud.com/39562" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39562</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: control lru_size for extent lock<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 277c6ceb21edf735a45c45eb5fe31480ba92b443</p> <p>Vitaly Fertman (vitaly.fertman@hpe.com) uploaded a new patch: <a href="https://review.whamcloud.com/39563" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39563</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: pool fixes<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 2451415ec9a55d4b413cc8983fb2a752b98c2b34</p> <p>Vitaly Fertman (vitaly.fertman@hpe.com) uploaded a new patch: <a href="https://review.whamcloud.com/39564" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39564</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: pool recalc forceful call<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 2d75b66d09bed60584cdc9eaf17bd6cbb5a851ee</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/39560/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39560/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: lru code cleanup<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 209a112eb153b4cc7429d70685a3bc2d7f51e45f</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/39561/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39561/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: cancel LRU improvement<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 3d4b5dacb3053f39d79d59860a903a19e76b9318</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/39562/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39562/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: control lru_size for extent lock<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 6052cc88eb1232ac3b0193f0d47881887a2dcfdc</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/39563/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39563/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: pool fixes<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 1806d6e8291758a835a846cd3c593e6699e56b15</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/39564/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39564/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: pool recalc forceful call<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: dd43ff345254f255d40c68488dcd913bcee93514</p> <p>I'm finding it hard to follow all the activity tracked under this ticket. There is still <a href="https://review.whamcloud.com/#/c/34584/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/34584/</a> unlanded - is that still needed?</p> <p>Peter, <a href="https://review.whamcloud.com/#/c/34584" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/34584</a> appears to be active.<br/> In addition, I see that <a href="https://review.whamcloud.com/#/c/33371/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/33371/</a> and <a href="https://review.whamcloud.com/#/c/35397/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/35397/</a> are still hanging out there too. However, <a href="https://review.whamcloud.com/#/c/35397/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/35397/</a> appears to be inactive. <a href="https://review.whamcloud.com/#/c/33371/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/33371/</a> was probably the replacement for it and appears active, but in turn it seems be handled with <a href="https://review.whamcloud.com/#/c/39735/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/39735/</a> (already merged). </p> <blockquote> <p>Peter, <a href="https://review.whamcloud.com/34584" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34584</a> appears to be active.<br/> In addition, I see that <a href="https://review.whamcloud.com/33371" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33371</a> and <a href="https://review.whamcloud.com/35397" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35397</a> are still hanging out there too. However, <a href="https://review.whamcloud.com/35397" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35397</a> appears to be inactive. <a href="https://review.whamcloud.com/33371" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33371</a> was probably the replacement for it and appears active, but in turn it seems be handled with <a href="https://review.whamcloud.com/39735" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39735</a> (already merged). </p></blockquote> <p>Both 33371 and 35397 have been abandoned, only 34584 remains to be landed.</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/34584/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34584/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: Do ELC on locks with no OSC object<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 36eca1017fe4643638d5f8bde646472fe8abb933</p> <p>Wow. Finally.</p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/41005" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41005</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: cancel osc_lock list traversal once found the lock is being used<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 64e70d2c6a12d7e460640ab208040aaf3c1e17ec</p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/41006" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41006</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: lru code cleanup<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: e60b7a8afd177b920e0728787b64312a6815be01</p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/41007" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41007</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: cancel LRU improvement<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 39253205ca7dc45d160b04eacb4cc20a1863f0ec</p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/41008" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41008</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: control lru_size for extent lock<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 6fa9e265501bef1f8fd87322f86a5011f7dc2c4a</p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/41009" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41009</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: pool fixes<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 7b1e97eb0ce991c3db67ad9ca031fc279636e72b</p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/41010" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41010</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: pool recalc forceful call<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 2964239f589d03fc4db7a1bb23ce774c74630f73</p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/41011" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41011</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: Do ELC on locks with no OSC object<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 20d6d6b9cffc6b8b27054bd9c24301e0de0cd9c0</p> <p>Any chance to land these to 2.12 LTS?</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/41005/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41005/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> osc: cancel osc_lock list traversal once found the lock is being used<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: <br/> Commit: eaee7c3cd636720fb925656f51c9a68c507849f6</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/41006/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41006/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: lru code cleanup<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: <br/> Commit: 2fd278af4caeb49ace25546c91e18b602e821042</p> <p>"Oleg Drokin &lt;green@whamcloud.com&gt;" merged in patch <a href="https://review.whamcloud.com/41007/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/41007/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11518" title="lock_count is exceeding lru_size" class="issue-link" data-issue-key="LU-11518"><del>LU-11518</del></a> ldlm: cancel LRU improvement<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: <br/> Commit: 8a5131183a2b353cb475ea5826623fe59013a5ac</p> Related LU-4300 LU-6390 LU-12095 LU-7236 LU-14221 Development Rank 1|i0046v: Rank (Obsolete) 9223372036854775807 Severity