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. > 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
