maria-developers team mailing list archive

[Sergey Vojtovich <svoj@xxxxxxxxxxx>]

Hi Sergei,

On Fri, Nov 28, 2014 at 12:00:49AM +0100, Sergei Golubchik wrote:
> 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.
API is fine, thanks!

> 
> 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.
Eh, that's what I was afraid of. Not seeing elements that were added at about
the same time should always be acceptable. Can't it miss elements that were
in the list before iteration started (because it has moved to a different
location)? The latter is unacceptable in many cases.

But let's see:
- print_cached_tables() - old debug stuff, remove it?
- I_S.OPEN_TABLES - seeing elements twice is not good, use PFS?
- close_cached_tables() - seeing elements twice is not a problem.
- close_cached_connection_tables() - seeing elements twice is not a problem.
- tc_purge() - seeing elements twice is not a problem.
- tc_add_table() - seeing elements twice is not a problem.
- mdl_iterate() - seeing elements twice is not good, use PFS?

> 
> > > > +  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.
What about this:
sizeof(mysql_rwlock_t)= 64 (just rough estimation)
sizeof(pad[128 - sizeof(mysql_rwlock_t)])= 64

It gives:
 +---------------+---------------+-------------+---------------+---------------+
 | rw_lock_t 32b | rw_lock_t 32b | padding 64b | rw_lock_t 32b | rw_lock_t 32b |
 +---------------+---------------+-------------+---------------+---------------+
 Cache line 128b |               Cache line 128b               |Cache line 128b
 ----------------+---------------------------------------------+----------------

Thanks,
Sergey