On Wed, May 11, 2016 at 09:49:20AM -0400, Matt Benjamin wrote: > > > syNM5pr-ZwBuR7lqnphEd-4kQUid0C9eRyta3ohOA/edit?usp=sharing > > > > > > There are several commits of interest that have a noticeable effect > > > on 128K sequential read performance: > > > > > > [..] > > > 2) https://github.com/ceph/ceph/commit/c474ee42 > > > > > > This commit had a very large impact, reducing performance by another > > > 20-25%. > > > > https://github.com/ceph/ceph/commit/c474ee42#diff-254555dde8dcfb7fb908791ab8214b92R318 > > I would check if temporarily forcing unique_lock_name() to return its arg > > (or other constant) would change things. If so, probably a more efficient way > > to construct unique lock name may be in order. > > ++ > > Naively, too, what unique_lock_name is doing amounts to: 1) creating extra of [a small] std::string [better fixed, but not a likely root cause?] 2) using Utils::stringify to hook ostream operators in the type passed in, and doing that on a new sstream; I don't thing "stringify" alone is a source of problems. This looks like a convenience function to make object dumping easier, so no real point in changing it, rather than that... > Maybe we should look horizontally at either speeding up or finding alternatives to stringify in other places? ... it's usage should be limited to non-performance-critical paths. In this particular case, probably checking for lockdep and refusing to act when it is disabled sounds like the least intrusive way to fix things. -- Piotr Dałek branch@xxxxxxxxxxxxxxxx http://blog.predictor.org.pl -- 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
