Today at the bluestore standup and perf meeting there was some
discussion regarding time spent in bitmap allocator locking and the
effect of 11014 on it. I ran a 4K random write test today with wip-denc
+ 11059 + 11014 and took a perf callgraph during 4K random writes.
As expected we are still picking up some buffer::list::append time in
encode_some even after the wip-denc changes:
- 5.45% 2.10% tp_osd_tp ceph-osd [.]
BlueStore::ExtentMap::encode_some
- 3.35% BlueStore::ExtentMap::encode_some
- 2.51% ceph::buffer::list::append
2.31% ceph::buffer::ptr::ptr
+ 1.24% __clone
But we also still see a fair amount of time spent in
BitMapAreaLeaf::child_check_n_lock:
- 5.26% 0.88% tp_osd_tp ceph-osd [.]
BitMapAreaLeaf::child_check_n_lock
- 4.39% BitMapAreaLeaf::child_check_n_lock
- 1.78% BitMapZone::lock_excl_try
1.49% pthread_mutex_trylock
- 1.59% BitMapZone::is_exhausted
+ 1.23% BitMapZone::check_locked
0.89% pthread_mutex_unlock
This is pretty comparable to what I was seeing prior to 11014, so it
doesn't appear to be having much effect on this specific issue.
Mark
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
