On 18-03-13 04:35 PM, Sage Weil wrote:
Radoslaw noticed that the nlock field in common/Mutex.h was slowing us
down by 5% (and was basically useless). Also, all of the conditional
behavior based on constructor argumenst were fixed at compile time.
This was mentioned on perf meeting two (or three?) weeks ago and it turns
out that it's not Mutex, but RWLock. See:
[..]
class Mutex {
private:
std::string name;
int id;
bool recursive;
bool lockdep;
bool backtrace; // gather backtrace on lock acquisition
pthread_mutex_t _m;
int nlock; /// <-- HERE
[..]
Incrementing or decrementing simple int field isn't going to slow anything
down by 5% unless it's some absurdly perverse workload, specifically
tailored to exercise this thing.
For RWLock:
[..]
class RWLock final
{
mutable pthread_rwlock_t L;
std::string name;
mutable int id;
mutable std::atomic<unsigned> nrlock = { 0 }, nwlock = { 0 }; /// <-- HERE
bool track, lockdep;
There's nrlock and nwlock, both atomics and his findings make much more
sense in that context. But then, there's a commit
https://github.com/ceph/ceph/commit/8feb27d821c76d00f76064fa04559e493be7ac32
which lets user disable usage of *both* nrlock and nwlock.
Instead of going with full re-work that might or might not work, maybe let's
add global option to disable/enable tracking on user demand, not just developer?
Still, I don't mind getting rid of our wrapper in favor of std::mutex.
--
Piotr Dałek
piotr.dalek@xxxxxxxxxxxx
https://www.ovh.com/us/
--
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
