Hi, ----- Original Message ----- > From: "Piotr Dałek" <branch@xxxxxxxxxxxxxxxx> > To: ceph-devel@xxxxxxxxxxxxxxx > Sent: Wednesday, May 11, 2016 9:35:04 AM > Subject: Re: Hammer vs Jewel librbd performance testing and git bisection results > 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; Maybe we should look horizontally at either speeding up or finding alternatives to stringify in other places? Matt > > -- > Piotr Dałek -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-707-0660 fax. 734-769-8938 cel. 734-216-5309 -- 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
