Hi, Sergey! On Nov 27, Sergey Vojtovich wrote:
I don't particularly like that solution. Could you try to switch to lock-free hash now?
I'll try to do the iterator asap
This is the change that allowed us to break through 27kTPS to 33kTPS. I don't like it either. My raw lf-hash prototype shows similar results.
I think we hardly need to have this bottleneck solved in 10.1 one way or another. So my question is: do you feel like we will be able to implement this all on time for 10.1?
I've pushed the iterator in bb-lf-iterator branch and reassigned the issue to you. Please take a look, if you cannot use the API, I could try to change it. But note, because of lock-free nature of the algorithm, the iterator will not see the snapshot of the hash, it might miss some elements that were added at about the same time. It might also see some elements twice.
+ struct st_locks + { + mysql_rwlock_t lock; + char pad[128];
In these cases I usually do: pad[128 - sizeof(mysql_rwlock_t)]; Hmm... strange that I didn't define macro for this, I thought I did.
Your suggestion guarantees that st_locks will be at least 128 bytes. But these 128 bytes may be split across 2 cache lines. Or malloc returns pointer aligned on cache line size?
No, it doesn't. As far as I know. But I only care that different locks go into different cache lines, they don't need to be aligned to 128 byte boundary. Regards, Sergei