On Fri, 16 Mar 2018, Radoslaw Zarzynski wrote: > On Tue, Mar 13, 2018 at 5:51 PM, Adam C. Emerson <aemerson@xxxxxxxxxx> wrote: > > We could kill off the string constructor overhead. > > +1. > > There is also another interesting thing here. std::string is pretty big > while being kept solely because of the late lockdep registration case > (+ some douts there). On my system it costs 32 bytes in comparison > to 40 the truly essential pthread_mutex_t needs. It's a significant > contribution to the fact Mutex spills on 2 cache lines. > > We might want to slightly rework the lockdep and delegate the std::string/ > string_view/C string holding far away from Mutex. Alternatively, switching to > to std::mutex for production builds might be enough. > > Finally we might also want to align and pad the stuff properly. IIRC in > the past there were reports regarding significant false sharing in our > structures. I think all of this is secondary (and mostly doesn't matter)... the *real* win will be using std::mutex instead of ceph::debugging_mutex. It almost doesn't matter how slow debugging_mutex is. Having fast debug builds is nice, but let's not get distracted from the real prize! sage > > Just have Mutex (or mutex_debug) store a std::string_view instead of a > > string. The caller would be RESPONSIBLE FOR MAKING SURE IT NEVER GOES > > AWAY > > And that's the painful part. I was just hunting for the Mutex instances > constructed with overridden default parameters and there was many > occurrences. It really looks the Mutex is very popular thing. Verifying > everything by hand might be a really time-consuming. Even a hack > could be acceptable in such situation, I guess. > > Regards, > Radosław Zarzyński > > > (at least not within the lifetime of the mutex) but in most cases > > where we're just passing in a static string "foo"sv would do > > that. Basically a more C++ friendly/idiomatic way for storing a const > > char* and passing a string literal. > > > > We could also just store a const char* and pass a string > > literal. Whichever people think will be less error prone. > > > > > > -- > > Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US > > IRC: Aemerson@OFTC, Actinic@Freenode > > 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9 > > -- > > 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 > -- > 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 > >
