Effect of 11014 on wip-denc bitmap allocator locking overhead

Effect of 11014 on wip-denc bitmap allocator locking overhead

[Mark Nelson]

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