maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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