Re: Hammer vs Jewel librbd performance testing and git bisection results

["Piotr Dałek" <branch@predictor.org.pl>]

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@predictor.org.pl
http://blog.predictor.org.pl
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html