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-7235 Lustre <p>dmu_object_alloc() in ZFS serializes object creations with a mutex:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">dmu_object_alloc(objset_t *os, dmu_object_type_t ot, <span class="code-object">int</span> dmu_object_type_t bonustype, <span class="code-object">int</span> bonuslen, dmu_tx_t *tx) { uint64_t object; uint64_t L2_dnode_count = DNODES_PER_BLOCK &lt;&lt; (DMU_META_DNODE(os)-&gt;dn_indblkshift - SPA_BLKPTRSHIFT); dnode_t *dn = NULL; <span class="code-object">int</span> restarted = B_FALSE; mutex_enter(&amp;os-&gt;os_obj_lock); </pre> </div></div> <p>this can be a bottleneck holding metadata performance much lower compared to ldiskfs where inode creation is more concurrent.</p> LU-7235

ZFS: dmu_object_alloc() serializes object creations

Improvement Minor Closed Fixed Alex Zhuravlev Alex Zhuravlev zfs Wed, 30 Sep 2015 13:03:02 +0000 Thu, 14 Jun 2018 21:39:05 +0000 Mon, 18 Sep 2017 12:07:07 +0000 0 6 <p>Initial observation</p> <p>The <tt>os_obj_lock</tt> lock only protects <tt>os-&gt;os_obj_next</tt>. Note there are over <b>100</b> additional mutex acquired while holding it.</p> <p>It looks like we can narrow the lock window by dropping it after we successfully holding the free dnode we found. As far as I can tell, the <tt>os_obj_lock</tt> lock does not need to be held across <tt>dnode_allocate()</tt> and <tt>dnode_rele()</tt>. Base on an ftrace forward call graph, it looks like that would cut the lock held duration from 948us down to 236us.</p> <p>See the attached call graph (line 153) for more context.</p> <p>I suspect this ticket can be closed, based on landings to upstream ZFS?</p> Blocker LU-2600 Development Rank 1|hzxp4v: Rank (Obsolete) 9223372036854775807