dmu_object_alloc-call-graph.txt
|
Blocker |
|||
| is blocking |
|
lustre metadata performance is very s... | Resolved |
[LU-7235] ZFS: dmu_object_alloc() serializes object creations Created: 30/Sep/15 Updated: 14/Jun/18 Resolved: 18/Sep/17 |
|
| Status: | Closed |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Alex Zhuravlev | Assignee: | Alex Zhuravlev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | zfs | ||
| Attachments: |
dmu_object_alloc-call-graph.txt
|
||||||||
| Issue Links: |
|
||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
dmu_object_alloc() in ZFS serializes object creations with a mutex: dmu_object_alloc(objset_t *os, dmu_object_type_t ot,
int dmu_object_type_t bonustype,
int bonuslen, dmu_tx_t *tx)
{
uint64_t object;
uint64_t L2_dnode_count = DNODES_PER_BLOCK <<
(DMU_META_DNODE(os)->dn_indblkshift - SPA_BLKPTRSHIFT);
dnode_t *dn = NULL;
int restarted = B_FALSE;
mutex_enter(&os->os_obj_lock);
this can be a bottleneck holding metadata performance much lower compared to ldiskfs where inode creation is more concurrent. |
| Comments |
| Comment by Don Brady (Inactive) [ 02/Oct/15 ] |
|
Initial observation The os_obj_lock lock only protects os->os_obj_next. Note there are over 100 additional mutex acquired while holding it. 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 os_obj_lock lock does not need to be held across dnode_allocate() and dnode_rele(). Base on an ftrace forward call graph, it looks like that would cut the lock held duration from 948us down to 236us. See the attached call graph (line 153) for more context. |
| Comment by Andreas Dilger [ 16/Sep/17 ] |
|
I suspect this ticket can be closed, based on landings to upstream ZFS? |