[#MDEV-5755] Scalability: let LOCK_open and THR

Comment by Sergey Vojtovich [ 2014-02-27 ]

Sergei, please review patch for this task.

Comment by Sergei Golubchik [ 2014-06-03 ]

just for the record (to repeat my email and your reply):

> To summarize Axel results:

>  at low concurency normal can be ~1% slower.

>  at high concurrency r/o - normal are up to 25% faster.

>  at high concurrency r/w - normal are up to 10% slower.

> That last result bothers me a litte.

Indeed. I'll check with Axel about it. Thanks for pointing it out!

Comment by Sergey Vojtovich [ 2014-06-04 ]

Axel, please benchmark suggested patches and assign back to me.

Comment by Axel Schwenke [ 2014-06-11 ]

I duplicated this task as TODO-629. Please check there for results.

Comment by Axel Schwenke [ 2015-08-10 ]

Work will continue here. I'll close TODO-629

Comment by Axel Schwenke [ 2015-08-10 ]

This is the patch that I tested vs. MariaDB-10.1.6

diff -urb mariadb-10.1.6/mysys/thr_lock.c mariadb-10.1.6-MDEV5755/mysys/thr_lock.c

--- mariadb-10.1.6/mysys/thr_lock.c     2015-07-23 14:19:50.000000000 +0000

+++ mariadb-10.1.6-MDEV5755/mysys/thr_lock.c    2015-08-10 10:50:57.646421280 +0000

@@ -440,7 +440,7 @@

   DBUG_ENTER("thr_lock_init");

   bzero((char*) lock,sizeof(*lock));

-  mysql_mutex_init(key_THR_LOCK_mutex, &lock->mutex, MY_MUTEX_INIT_FAST);

+  mysql_mutex_init(key_THR_LOCK_mutex, &lock->mutex, MY_MUTEX_INIT_SLOW);

   lock->read.last= &lock->read.data;

   lock->read_wait.last= &lock->read_wait.data;

   lock->write_wait.last= &lock->write_wait.data;

Only in mariadb-10.1.6-MDEV5755/mysys: thr_lock.c.orig

diff -urb mariadb-10.1.6/sql/table_cache.h mariadb-10.1.6-MDEV5755/sql/table_cache.h

--- mariadb-10.1.6/sql/table_cache.h    2015-07-23 14:19:50.000000000 +0000

+++ mariadb-10.1.6-MDEV5755/sql/table_cache.h   2015-08-10 11:34:17.916394975 +0000

@@ -139,7 +139,7 @@

     TDC_element *element= (TDC_element*) (arg + LF_HASH_OVERHEAD);

     DBUG_ENTER("lf_alloc_constructor");

     mysql_mutex_init(key_TABLE_SHARE_LOCK_table_share,

-                     &element->LOCK_table_share, MY_MUTEX_INIT_FAST);

+                     &element->LOCK_table_share, MY_MUTEX_INIT_SLOW);

     mysql_cond_init(key_TABLE_SHARE_COND_release, &element->COND_release, 0);

     element->m_flush_tickets.empty();

     element->all_tables.empty();

Comment by Axel Schwenke [ 2015-08-10 ]

Here is the result that I got from running sysbench OLTP with a single table (8 mio rows, ram disk) on a Power8 VM with cores/40 threads:

Conclusion: normal mutexes are a bit slower than fast mutexes.

I shall repeat this benchmark on an Intel machine, but currently I don't have a sufficiently large machine avaiable.

Comment by Axel Schwenke [ 2015-08-12 ]

And here is the result for the same benchmark running on a 4 core (8 threads) Intel machine.

Again the performance is a bit worse with slow mutexes. Conclusion: keep the fast mutexes.

Comment by Sergey Vojtovich [ 2015-08-19 ]

Locking scheme has changed a lot since this analysis was performed, so we can assume this task is not relevant anymore.

[MDEV-5755] Scalability: let LOCK_open and THR_LOCK::mutex be normal mutexes Created: 2014-02-27 Updated: 2015-08-19 Resolved: 2015-08-19
Status:	Closed
Project:	MariaDB Server
Component/s:	OTHER
Affects Version/s:	10.0.8
Fix Version/s:	N/A