- developers - lists.mariadb.org

Re: [Maria-developers] Rev 4056: MDEV-5616 - Deadlock between CREATE/DROP FUNCTION and SELECT from view
by Sergei Golubchik 13 Feb '14

13 Feb '14

Hi, Sergey! Ok to push. A couple of comments below. On Feb 07, Sergey Vojtovich wrote: > revno: 4056 > revision-id: svoj(a)mariadb.org-20140207100451-8pnzn85pjjwvwfs4 > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5616 > timestamp: Fri 2014-02-07 14:04:51 +0400 > message: > MDEV-5616 - Deadlock between CREATE/DROP FUNCTION and SELECT from view > > Deadlock happened due to mixed lock order. > CREATE/DROP function: wrlock(THR_LOCK_udf) -> lock(LOCK_open) > SELECT from view: lock(LOCK_open) -> rdlock(THR_LOCK_udf) > > Fixed CREATE/DROP function so that LOCK_open does not intersect with > wrlock(THR_LOCK_udf). > > 10.0 is not affected: it doesn't hold LOCK_open while opening view. I'm pretty sure it'll auto-merge and nobody will remember this warning at that time. So this patch will be in 10.0. Perhaps you should add #if MYSQL_VERSION_ID > 50600 #error don't merge into 10.0 #endif ? Or, may be, it's not a big deal to have it in 10.0... > === modified file 'sql/sql_udf.cc' > --- a/sql/sql_udf.cc 2012-03-27 23:04:46 +0000 > +++ b/sql/sql_udf.cc 2014-02-07 10:04:51 +0000 > @@ -466,7 +467,11 @@ int mysql_create_function(THD *thd,udf_f > if ((save_binlog_row_based= thd->is_current_stmt_binlog_format_row())) > thd->clear_current_stmt_binlog_format_row(); > > + tables.init_one_table("mysql", 5, "func", 4, "func", TL_WRITE); I know it's a old line that you've moved and it's a matter of taste anyway, so up to you, but generally I prefer to see STRING_WITH_LEN here. It 1) makes a certain class of typos impossible; 2) documents the code, one doesn't need to think what these 4 and 5 stand for. Regards, Sergei

2 1

Re: [Maria-developers] Rev 3967: MDEV-5597 - Reduce usage of LOCK_open: LOCK_flush
by Sergei Golubchik 12 Feb '14

12 Feb '14

Hi, Sergey! On Jan 31, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 3967 > revision-id: svoj(a)mariadb.org-20140131141943-fjyyih3h92lek62n > parent: svoj(a)mariadb.org-20140130124905-vy28zbs9swlpg8uq > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Fri 2014-01-31 18:19:43 +0400 > message: > MDEV-5597 - Reduce usage of LOCK_open: LOCK_flush > > Replaced LOCK_flush with per-share conditional variable. > === modified file 'sql/table_cache.cc' > --- a/sql/table_cache.cc 2014-01-30 12:49:05 +0000 > +++ b/sql/table_cache.cc 2014-01-31 14:19:43 +0000 > @@ -945,6 +949,7 @@ bool tdc_remove_table(THD *thd, enum_tdc > if ((share= tdc_delete_share(db, table_name))) > { > I_P_List <TABLE, TABLE_share> purge_tables; > + uint my_refs= 1; > > mysql_mutex_lock(&LOCK_open); > /* > @@ -969,28 +974,48 @@ bool tdc_remove_table(THD *thd, enum_tdc > if (kill_delayed_threads) > kill_delayed_threads_for_table(share); > > -#ifndef DBUG_OFF > - if (remove_type == TDC_RT_REMOVE_NOT_OWN) > + if (remove_type == TDC_RT_REMOVE_NOT_OWN || > + remove_type == TDC_RT_REMOVE_NOT_OWN_KEEP_SHARE) > { > TABLE_SHARE::All_share_tables_list::Iterator it(share->tdc.all_tables); > while ((table= it++)) > + { > + my_refs++; > DBUG_ASSERT(table->in_use == thd); > + } > } > -#endif > - > - mysql_rwlock_rdlock(&LOCK_flush); > + DBUG_ASSERT(share->tdc.all_tables.is_empty() || remove_type != TDC_RT_REMOVE_ALL); > mysql_mutex_unlock(&LOCK_open); > > while ((table= purge_tables.pop_front())) > intern_close_table(table); > - mysql_rwlock_unlock(&LOCK_flush); > > - DBUG_ASSERT(share->tdc.all_tables.is_empty() || remove_type != TDC_RT_REMOVE_ALL); > - tdc_release_share(share); > + if (remove_type != TDC_RT_REMOVE_UNUSED) > + { > + /* > + Even though current thread holds exclusive metadata lock on this share > + (asserted above), concurrent FLUSH TABLES threads may be in process of > + closing unused table instances belonging to this share. E.g.: > + thr1 (FLUSH TABLES): table= share->tdc.free_tables.pop_front(); > + thr1 (FLUSH TABLES): share->tdc.all_tables.remove(table); > + thr2 (ALTER TABLE): tdc_remove_table(); > + thr1 (FLUSH TABLES): intern_close_table(table); > + > + Current remove type assumes that all table instances (except for those > + that are owned by current thread) must be closed before > + thd_remove_table() returns. Wait for such tables here. > + > + Unfortunately TABLE_SHARE::wait_for_old_version() cannot be used here > + because it waits for all table instances, whereas we have to wait only > + for those that are not owned by current thread. > + */ > + mysql_mutex_lock(&share->tdc.LOCK_table_share); > + while (share->tdc.ref_count > my_refs) > + mysql_cond_wait(&share->tdc.COND_release, &share->tdc.LOCK_table_share); > + mysql_mutex_unlock(&share->tdc.LOCK_table_share); I'm sorry, I don't understand that at all. Why my_refs is only incremented in debug builds? In non-debug builds you wait until all tables but one are closed, in debug builds you may keep more than one table opened. You wait here on a condition, how do you know there's FLUSH TABLES (or anything at all) running that will signal this condition? > + } > > - /* Wait for concurrent threads to free unused objects. */ > - mysql_rwlock_wrlock(&LOCK_flush); > - mysql_rwlock_unlock(&LOCK_flush); > + tdc_release_share(share); > > found= true; > } Regards, Sergei

2 4

[Maria-developers] MariaDB config for Akonadi - suggestions?
by Sergey Petrunia 12 Feb '14

12 Feb '14

Hi, Daniel Vratil from Akonadi (a PIM manager for KDE) has asked me at FOSDEM about optimal MariaDB configuration for Akonadi. Some specific questions: * innodb_flush_log_at_trx_commit. Currently, Akonadi uses innodb_flush_log_at_trx_commit=2 which as far as I understand can cause up to 1 second of changes to be lost. Using value of 1 (always flush on commit) should be safer, but maybe it would put an unnecessary load on the system? Akonadi's use case has a bit different idea of what load is - there is only one person making changes, but the system is likely to be a laptop where one cares about battery life, etc. * innodb_buffer_pool_size=80M. The dataset size can vary from very small to up to 1-1.5Gb. Some users have very little data and complain that 80M is too much. Does anybody have an experience with using very small innodb_buffer_pool_size? Please find the full config file below: === Akonadi configuration file === # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp <kris(a)mysql.com> # [mysqld] # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled # sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat # sql_mode=strict_trans_tables # DEBUGGING: # log all queries, useful for debugging but generates an enormous amount of data # log=mysql.full # log queries slower than n seconds, log file name relative to datadir (for debugging only) # log_slow_queries=mysql.slow # long_query_time=1 # log queries not using indices, debug only, disable for production use # log_queries_not_using_indexes=1 # # mesure database size and adjust innodb_buffer_pool_size # SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema"); # NOTES: # Keep Innob_log_waits and keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables) #expire_logs_days=3 #sync_bin_log=0 # Use UTF-8 encoding for tables character_set_server=utf8 collation_server=utf8_general_ci # use InnoDB for transactions and better crash recovery default_storage_engine=innodb # memory pool InnoDB uses to store data dictionary information and other internal data structures (default:1M) # Deprecated in MySQL >= 5.6.3 innodb_additional_mem_pool_size=1M # memory buffer InnoDB uses to cache data and indexes of its tables (default:128M) # Larger values means less I/O innodb_buffer_pool_size=80M # Create a .ibd file for each table (default:0) innodb_file_per_table=1 # Write out the log buffer to the log file at each commit (default:1) innodb_flush_log_at_trx_commit=2 # Buffer size used to write to the log files on disk (default:1M for builtin, 8M for plugin) # larger values means less I/O innodb_log_buffer_size=1M # Size of each log file in a log group (default:5M) larger means less I/O but more time for recovery. innodb_log_file_size=64M # # error log file name, relative to datadir (default:hostname.err) log_error=mysql.err # print warnings and connection errors (default:1) log_warnings=2 # Convert table named to lowercase lower_case_table_names=1 # Maximum size of one packet or any generated/intermediate string. (default:1M) max_allowed_packet=32M # Maximum simultaneous connections allowed (default:100) max_connections=256 # The two options below make no sense with prepared statements and/or transactions # (make sense when having the same query multiple times) # Memory allocated for caching query results (default:0 (disabled)) query_cache_size=0 # Do not cache results (default:1) query_cache_type=0 # Do not use the privileges mechanisms skip_grant_tables # Do not listen for TCP/IP connections at all skip_networking # The number of open tables for all threads. (default:64) table_open_cache=200 # How many threads the server should cache for reuse (default:0) thread_cache_size=3 # wait 365d before dropping the DB connection (default:8h) wait_timeout=31536000 # We use InnoDB, so don't let MyISAM eat up memory key_buffer_size=16K [client] default-character-set=utf8 BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] Minor glitch when doing out of tree cmake build
by Andrew McDonnell 10 Feb '14

10 Feb '14

Hi, I like to build MariaDB in a separate directory to keep the source tree clean. This works for me as follows: cd path/to/maria/source mkdir mybuildir cd mybuildir cmake .. "-DWITH_PLUGIN_ARIA=1 (etc...)" make mysql-test/mysql-test-run --suite oqgraph (etc) However when I want to use this build to create a non-MTR database as follows: MARIA_HOME=path/to/maria/source MARIA_BUILD=path/to/maria/source/mybuilddir sh $MARIA_BUILD/scripts/mysql_install_db \ --srcdir=$MARIA_HOME \ --builddir=$MARIA_BUILD \ --datadir=path/to/data --defaults-file=... This fails with FATAL ERROR: Could not find maria/source/sql/share/english/errmsg.sys Different combinations of --srcdir and --builddir produce similar but different errors. I tracked down where the files are set to to lines 263..303 of scripts/mysql_install_db.sh >From my reading of the help: --builddir=path If using --srcdir with out-of-directory builds, you will need to set this to the location of the build directory where built files reside. --srcdir=path The path to the MariaDB source directory. This option uses the compiled binaries and support files within the source tree, useful for if you don't want to install MariaDB yet and just want to create the system tables. I was able to make the install script work with the following patch === modified file 'scripts/mysql_install_db.sh' --- scripts/mysql_install_db.sh 2014-02-03 14:22:39 +0000 +++ scripts/mysql_install_db.sh 2014-02-08 11:52:52 +0000 @@ -267,7 +267,7 @@ bindir="$basedir/client" extra_bindir="$basedir/extra" mysqld="$basedir/sql/mysqld" - langdir="$srcdir/sql/share/english" + langdir="$basedir/sql/share/english" pkgdatadir="$srcdir/scripts" scriptdir="$srcdir/scripts" elif test -n "$basedir" What I dont know enough about, is whether this breaks other scenarios? any advice appreciated, thanks, Andrew -- http://blog.oldcomputerjunk.net https://launchpad.net/~andymc73 https://github.com/andymc73 Twitter: @pastcompute GPG: http://www.andrewmcdonnell.net/gpg.html

2 3

Re: [Maria-developers] Rev 4056: MDEV-5607: Query cache destroys uninitialized rwlock
by Sergei Golubchik 10 Feb '14

10 Feb '14

Hi, Sanja! On Feb 08, sanja(a)askmonty.org wrote: > ------------------------------------------------------------ > revno: 4056 > revision-id: sanja(a)askmonty.org-20140208132448-qdkkpdncnya0tr6j > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-5607 > timestamp: Sat 2014-02-08 15:24:48 +0200 > message: > MDEV-5607: Query cache destroys uninitialized rwlock > > - Resize destroyed rw_lock twice, now it is prevented. > - Trash destroyed rw lock. > === modified file 'include/mysql/psi/mysql_thread.h' > --- a/include/mysql/psi/mysql_thread.h 2013-01-11 00:03:43 +0000 > +++ b/include/mysql/psi/mysql_thread.h 2014-02-08 13:24:48 +0000 > @@ -16,6 +16,8 @@ > #ifndef MYSQL_THREAD_H > #define MYSQL_THREAD_H > > +#include <my_valgrind.h> This is not ok. Files under include/mysql/ are Plugin API files, they should be clean from internal includes. You cannot include my_valgrind.h from there. Do it in my_pthread.h Regards, Sergei

2 1

[Maria-developers] Please merge 5.3 -> 5.5, mdev-5468
by Sergei Petrunia 10 Feb '14

10 Feb '14

Hello Igor, Your fix for mdev-5468 is the oldest fix in 5.3 that is not merged to 5.5. I've tried merging it. The changes in the code auto-merged, but after that the testsuite failed with crashes. Could you please merge mdev-5468 from 5.3 to 5.5? BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] Rev 4056: MDEV-5607: Query cache destroys uninitialized rwlock in file:///home/bell/maria/bzr/work-maria-5.5-MDEV-5607/
by Sergey Vojtovich 10 Feb '14

10 Feb '14

Hi Sanja, JFYI: while reporting this bug I came up with two questions that I couldn't answer quickly. Probably they make sense, if not just ignore them: 1. This code was introduced with https://bugs.launchpad.net/maria/+bug/782223, revision: wlad(a)montyprogram.com-20110514163720-rmico2qegtptjguk <quot> The callstack leading of "free" containing critical section is: mysqld!free my_no_flags_free Query_cache::free_cache Query_cache::resize fix_query_cache_size set_var::update sql_set_variables mysql_execute_command mysql_parse <quot> It means that this code was supposed to be executed exactly by Query_cache::resize(), where you disable it. Question: if this code is not supposed to be executed by ::resize(), is it needed at all? 2. In Query_cache::resize() I can see block-level locks are acquired with the following comment: <quot> Wait for all readers and writers to exit. When the list of all queries is iterated over with a block level lock, we are done. </quot> Isn't it needed in ::free_cache() also? Regards, Sergey On Sat, Feb 08, 2014 at 01:25:11PM +0000, sanja(a)askmonty.org wrote: > At file:///home/bell/maria/bzr/work-maria-5.5-MDEV-5607/ > > ------------------------------------------------------------ > revno: 4056 > revision-id: sanja(a)askmonty.org-20140208132448-qdkkpdncnya0tr6j > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-5607 > timestamp: Sat 2014-02-08 15:24:48 +0200 > message: > MDEV-5607: Query cache destroys uninitialized rwlock > > - Resize destroyed rw_lock twice, now it is prevented. > - Trash destroyed rw lock. > === modified file 'include/my_valgrind.h' > --- a/include/my_valgrind.h 2012-03-22 11:31:09 +0000 > +++ b/include/my_valgrind.h 2014-02-08 13:24:48 +0000 > @@ -13,7 +13,8 @@ > along with this program; if not, write to the Free Software > Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ > > - > +#ifndef my_valgrind_h > +#define my_valgrind_h > /* Some defines to make it easier to use valgrind */ > #include <m_string.h> /* bfill */ > > @@ -45,3 +46,4 @@ > #define TRASH_FREE(A,B) TRASH_FILL(A,B,0x8F) > #define TRASH(A,B) TRASH_FREE(A,B) > > +#endif //my_valgrind_h > > === modified file 'include/mysql/psi/mysql_thread.h' > --- a/include/mysql/psi/mysql_thread.h 2013-01-11 00:03:43 +0000 > +++ b/include/mysql/psi/mysql_thread.h 2014-02-08 13:24:48 +0000 > @@ -16,6 +16,8 @@ > #ifndef MYSQL_THREAD_H > #define MYSQL_THREAD_H > > +#include <my_valgrind.h> > + > /** > @file mysql/psi/mysql_thread.h > Instrumentation helpers for mysys threads, mutexes, > @@ -714,6 +716,7 @@ static inline int inline_mysql_prlock_in > static inline int inline_mysql_rwlock_destroy( > mysql_rwlock_t *that) > { > + int res; > #ifdef HAVE_PSI_INTERFACE > if (likely(PSI_server && that->m_psi)) > { > @@ -721,7 +724,9 @@ static inline int inline_mysql_rwlock_de > that->m_psi= NULL; > } > #endif > - return rwlock_destroy(&that->m_rwlock); > + res= rwlock_destroy(&that->m_rwlock); > + TRASH(that, sizeof(*that)); > + return res; > } > > #ifndef DISABLE_MYSQL_PRLOCK_H > > === modified file 'mysql-test/r/query_cache.result' > --- a/mysql-test/r/query_cache.result 2013-10-16 13:07:25 +0000 > +++ b/mysql-test/r/query_cache.result 2014-02-08 13:24:48 +0000 > @@ -2077,6 +2077,21 @@ drop procedure p1; > drop table t1; > set GLOBAL query_cache_size=1355776; > SET GLOBAL userstat=default; > +# > +#MDEV-5607 Query cache destroys uninitialized rwlock > +# > +SET @global_query_cache_size = @@global.query_cache_size; > +SET @global_query_cache_type = @@global.query_cache_type; > +SET GLOBAL query_cache_type = default; > +SET GLOBAL query_cache_size = default; > +SET GLOBAL query_cache_type = ON; > +SET GLOBAL query_cache_size = 131072; > +CREATE TABLE t1(a INT); > +SELECT * FROM t1; > +a > +SET GLOBAL query_cache_size = @global_query_cache_size; > +SET GLOBAL query_cache_type = @global_query_cache_type; > +DROP TABLE t1; > End of 5.5 tests > restore defaults > SET GLOBAL query_cache_type= default; > > === modified file 'mysql-test/t/query_cache.test' > --- a/mysql-test/t/query_cache.test 2013-10-16 13:07:25 +0000 > +++ b/mysql-test/t/query_cache.test 2014-02-08 13:24:48 +0000 > @@ -1708,6 +1708,23 @@ drop table t1; > set GLOBAL query_cache_size=1355776; > SET GLOBAL userstat=default; > > +--echo # > +--echo #MDEV-5607 Query cache destroys uninitialized rwlock > +--echo # > +SET @global_query_cache_size = @@global.query_cache_size; > +SET @global_query_cache_type = @@global.query_cache_type; > +SET GLOBAL query_cache_type = default; > +SET GLOBAL query_cache_size = default; > +SET GLOBAL query_cache_type = ON; > +SET GLOBAL query_cache_size = 131072; > + > +CREATE TABLE t1(a INT); > +SELECT * FROM t1; > + > +SET GLOBAL query_cache_size = @global_query_cache_size; > +SET GLOBAL query_cache_type = @global_query_cache_type; > +DROP TABLE t1; > + > --echo End of 5.5 tests > > --echo restore defaults > > === modified file 'sql/sql_cache.cc' > --- a/sql/sql_cache.cc 2013-11-19 12:16:25 +0000 > +++ b/sql/sql_cache.cc 2014-02-08 13:24:48 +0000 > @@ -1326,6 +1326,7 @@ ulong Query_cache::resize(ulong query_ca > query->unlock_n_destroy(); > block= block->next; > } while (block != queries_blocks); > + queries_blocks= NULL; // avoid second destroying by free_cache > } > free_cache(); > > > === modified file 'storage/perfschema/ha_perfschema.cc' > --- a/storage/perfschema/ha_perfschema.cc 2012-03-27 23:04:46 +0000 > +++ b/storage/perfschema/ha_perfschema.cc 2014-02-08 13:24:48 +0000 > @@ -19,9 +19,9 @@ > */ > > #include "my_global.h" > +#include "sql_plugin.h" > #include "my_pthread.h" > #include "my_atomic.h" > -#include "sql_plugin.h" > #include "mysql/plugin.h" > #include "ha_perfschema.h" > #include "pfs_engine_table.h" > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1

[Maria-developers] Buildbot trees for spider and mroonga
by Alexander Barkov 10 Feb '14

10 Feb '14

Hi Kentoku, Currently you use your own trees for Mroonga and Spider development, e.g. bzr+ssh://bazaar.launchpad.net/~mroonga/maria/mroonga/ Would you mind to move development into trees under ~maria-captains location, for example: bzr+ssh://bazaar.launchpad.net/~maria-captains/maria/10.0-mroonga/ bzr+ssh://bazaar.launchpad.net/~maria-captains/maria/10.0-spider/ This will give an great advantage to have every revision compiled and tested on a wide variety of operating systems (this is done automatically by MariaDB Build Bot), and also will help us to merge your updates into the main 10.0 tree easier. Note, development in these trees should be done "incrementally". Things like "bzr push --overwrite" are not desirable, to avoid problems with BiildBot and with merges. Hope this is not a big problem. Thanks.

3 4

[Maria-developers] Updating OQGRAPH tables
by Ian Gilfillan 08 Feb '14

08 Feb '14

Hi I have been struggling to get OQGRAPH working with MariaDB 10.0.7. The system has been hanging and crashing frequently. I will post as bugs if I can recreate them, but this question is simply, how can I update the data? On a new install of MariaDB 10.0.7 and OQGRAPH - I create the sample tables at https://mariadb.com/kb/en/oqgraph-examples/#creating-a-table-with-weight - I then update the oq2_backing table. The changes reflect on the oq2_backing table, not the oq2_graph table: UPDATE oq2_backing SET weight=4 WHERE origid=2 AND destid=6; SELECT * FROM oq2_backing; +--------+--------+--------+ | origid | destid | weight | +--------+--------+--------+ | 1 | 2 | 1 | | 2 | 3 | 1 | | 2 | 6 | 4 | | 3 | 4 | 3 | | 4 | 5 | 1 | | 5 | 6 | 2 | +--------+--------+--------+ SELECT * FROM oq2_graph; +-------+--------+--------+--------+------+--------+ | latch | origid | destid | weight | seq | linkid | +-------+--------+--------+--------+------+--------+ | NULL | 1 | 2 | 1 | NULL | NULL | | NULL | 2 | 3 | 1 | NULL | NULL | | NULL | 2 | 6 | 10 | NULL | NULL | | NULL | 3 | 4 | 3 | NULL | NULL | | NULL | 4 | 5 | 1 | NULL | NULL | | NULL | 5 | 6 | 2 | NULL | NULL | +-------+--------+--------+--------+------+--------+ How can I make changes that reflect on the table? thanks, ian

2 2

[Maria-developers] GCC native thread local storage (Was: [Maria-discuss] xtradb in 10.0)
by Kristian Nielsen 07 Feb '14

07 Feb '14

Laurynas Biveinis <laurynas.biveinis(a)gmail.com> writes: > We have another platform-specific addition: thread-local storage > implemented by __thread GCC keyword, which is GNU specific. This is Hm, this is interesting, I was not aware of the __thread feature. This looks to be much more efficient than pthread_getspecific(), which is one of the top functions in the profiles for sysbench readonly: static __thread long tcount = 0; long bump(long del) { return (tcount += del); } 0000000000000000 <bump>: 0: 48 89 f8 mov %rdi,%rax 3: 64 48 03 04 25 00 00 add %fs:0x0,%rax a: 00 00 c: 64 48 89 04 25 00 00 mov %rax,%fs:0x0 13: 00 00 15: c3 retq It is just a single instruction using %fs: addressing to access the thread_local storage. Apparently the linker resolves the %fs: offset in the resulting binary: 0000000000400580 <bump>: 400580: 48 89 f8 mov %rdi,%rax 400583: 64 48 03 04 25 e0 ff add %fs:0xffffffffffffffe0,%rax 40058a: ff ff 40058c: 64 48 89 04 25 e0 ff mov %rax,%fs:0xffffffffffffffe0 400593: ff ff 400595: c3 retq 00000000004005a0 <bump2>: 4005a0: 48 89 f8 mov %rdi,%rax 4005a3: 64 48 03 04 25 f0 ff add %fs:0xfffffffffffffff0,%rax 4005aa: ff ff 4005ac: 64 48 89 04 25 f0 ff mov %rax,%fs:0xfffffffffffffff0 4005b3: ff ff 4005b5: c3 retq So that could be very promising for an easy way to tweak out a little more performance. Something to look into at some point. - Kristian.

1 0