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-5749 Lustre <p><a href="https://jira.whamcloud.com/browse/LU-5331" title="qsd_handler.c:1139:qsd_op_adjust()) ASSERTION( qqi ) failed" class="issue-link" data-issue-key="LU-5331"><del>LU-5331</del></a> introduced lu_site::ls_purge_mutex to serialize lu_site_purge(). But in osd-zfs, when every new object is created, lu_object_limit() is called which calls lu_site_purge() if the cache is too big.</p> <p>Contention on the mutex can happen when multiple threads are creating objects and the cache is near the lu_cache_nr limit. In <a href="https://jira.whamcloud.com/browse/LU-5747" title="NULL pointer dereference in task_rq_lock when running mds-survey" class="issue-link" data-issue-key="LU-5747"><del>LU-5747</del></a> I saw stacks like:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> [&lt;ffffffff8106306c&gt;] try_to_wake_up+0x3c/0x3e0 [&lt;ffffffffa0f0e219&gt;] ? echo_object_free+0x159/0x2f0 [obdecho] [&lt;ffffffff81063465&gt;] wake_up_process+0x15/0x20 [&lt;ffffffff8150f7e4&gt;] __mutex_unlock_slowpath+0x44/0x60 [&lt;ffffffff8150f79b&gt;] mutex_unlock+0x1b/0x20 [&lt;ffffffffa07a4907&gt;] lu_site_purge+0x3f7/0x4e0 [obdclass] [&lt;ffffffffa07a4e31&gt;] lu_object_limit+0x71/0x80 [obdclass] [&lt;ffffffffa07a4f93&gt;] lu_object_find_try+0x153/0x2b0 [obdclass] </pre> </div></div> <p>Which indicated contention on the mutex. So this may hurt object creation rates on osd-zfs. But I don't have any data to support it yet, due to <a href="https://jira.whamcloud.com/browse/LU-5747" title="NULL pointer dereference in task_rq_lock when running mds-survey" class="issue-link" data-issue-key="LU-5747"><del>LU-5747</del></a>.</p> LU-5749

osd-zfs: object creation may serialize on lu_site::ls_purge_mutex

Improvement Minor Resolved Duplicate Alex Zhuravlev Isaac Huang RZ_LS zfs Thu, 16 Oct 2014 03:11:13 +0000 Wed, 13 Feb 2019 07:39:24 +0000 Wed, 13 Feb 2019 07:39:24 +0000 Lustre 2.7.0 0 5 <p>It probably makes sense for lu_site_purge() to use <tt>mutex_trylock()</tt> and just return immediately if <tt>ls_purge_mutex</tt> is held and another thread is dropping the cache (need a static variable that is updated by the thread holding ls_purge_mutex indicating if it is doing a full purge or not). There is no reason for other threads to be blocked if one is already dropping the entire cache. There is also no reason for threads to block when doing a limited cache shrink if another thread is also doing a limited shrink.</p> <p>I hit it on master:<br/> <a href="https://testing.hpdd.intel.com/test_sets/a6c0f402-d2ed-11e4-a357-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/a6c0f402-d2ed-11e4-a357-5254006e85c2</a></p> <p>Fixed via patch <a href="http://review.whamcloud.com/19082" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/19082</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-7896" title="lu_object_limit() is called too frequently" class="issue-link" data-issue-key="LU-7896"><del>LU-7896</del></a>: do not call lu_site_purge() for single object exceed</tt>".</p> Related LU-5331 LU-7896 Development Rank 1|hzwyo7: Rank (Obsolete) 16144