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-6676 Lustre <p>In current implementation of LDLM lock, if a lock is in waiting list and blocks a newly enqueued lock, the waiting lock will be added into work_list and blocking AST will be sent against this lock.</p> <p>This is a waste of effort because the lock is not granted yet, usually the client holds a reader/writer counter so blocking AST can't do anything to the lock;</p> <p>Actually the server doesn't need to send the blocking AST RPC for waiting locks, instead it can just set LDLM_FL_AST_SENT flag and this flag will be piggied back by completion AST later.</p> LU-6676

Excessive blocking ast RPC for LDLM locks in waiting list

Improvement Minor Open Unresolved WC Triage Jinshan Xiong Tue, 2 Jun 2015 17:06:47 +0000 Fri, 10 Jul 2015 18:47:06 +0000 0 3 <p>Do we really send blocking AST, though?</p> <p>In ldlm_Server_blockingast we have this bit:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> lock_res_and_lock(lock); if (lock-&gt;l_granted_mode != lock-&gt;l_req_mode) { /* this blocking AST will be communicated as part of the * completion AST instead */ unlock_res_and_lock(lock); ptlrpc_req_finished(req); LDLM_DEBUG(lock, "lock not granted, not sending blocking AST"); RETURN(0); } </pre> </div></div> <p>So nothing is sent.</p> <p>I missed this part. But again this is not good because those locks in waiting list don't have to be added into work_list in the first place.</p> <p>Which waiting list do you mean?<br/> The resource waiting list? we absolutely must add the locks there because that's how we know to grant them once the lock that blocks them goes away.</p> <p>The waiting list for timer to evict the clients? we don't add there until the lock is actually granted.</p> <p>Can you please elaborate?</p> <p>For example, for extent lock, in ldlm_process_extent_lock():</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">ldlm_process_extent_lock() { ... rc2 = ldlm_extent_compat_queue(&amp;res-&gt;lr_waiting, lock, flags, err, &amp;rpc_list, &amp;contended_locks); ... } ldlm_extent_compat_queue() { ... <span class="code-keyword">if</span> (!work_list) RETURN(0); <span class="code-comment">/* don't count conflicting glimpse locks */</span> <span class="code-keyword">if</span> (lock-&gt;l_req_mode == LCK_PR &amp;&amp; lock-&gt;l_policy_data.l_extent.start == 0 &amp;&amp; lock-&gt;l_policy_data.l_extent.end == OBD_OBJECT_EOF) check_contention = 0; *contended_locks += check_contention; compat = 0; <span class="code-keyword">if</span> (lock-&gt;l_blocking_ast) ldlm_add_ast_work_item(lock, req, work_list); ... } </pre> </div></div> <p>If the lock is in the waiting list, can we assume that the CP AST is not sent for this lock? If that is the case, we don't need to add the lock into the @work_list, instead we can set the AST_SENT bit directly because we know there exists a CP AST down the road.</p> <p>And in ldlm_server_completion_ast():</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> ... <span class="code-comment">/* We only send real blocking ASTs after the lock is granted */</span> lock_res_and_lock(lock); <span class="code-keyword">if</span> (ldlm_is_ast_sent(lock)) { body-&gt;lock_flags |= ldlm_flags_to_wire(LDLM_FL_AST_SENT); <span class="code-comment">/* Copy AST flags like LDLM_FL_DISCARD_DATA. */</span> body-&gt;lock_flags |= ldlm_flags_to_wire(lock-&gt;l_flags &amp; LDLM_FL_AST_MASK); ... </pre> </div></div> <p>If it has bit AST_SENT, it will be brought to client, so that client will have CP_PENDING set correspondingly.</p> Development Rank 1|hzxepj: Rank (Obsolete) 9223372036854775807 Severity