Kristian, Uh, Thank you for looking into this.
You ask good question re: INNODB_RW_LOCKS_USE_ATOMICS, this is actually one of main points of XtraDB to improve scalability on 8CPU+ boxes, so we just rely on it. XtraDB can be built without INNODB_RW_LOCKS_USE_ATOMICS, but effect may be opposite - we can see slowdown instead of improvement. I am not sure what to do with this, I also need to look into InnoDB-plugin 1.0.3, what solution they have and may be use new InnoDB rw_locks instead of ours. Anyway - this is something to discuss. About tests you should execute setup.sh from storage/innobase before running test, as it patches main test suite by InnoDB specific tests. I did not want to put them into main test suite to keep all changes only to storage/innobase repository. In our tests only two tests do not pass after patches - it is main.variables_big and main.read_many_rows_innodb, but they also do not pass in native InnoDB-plugin. Again what to do with tests it is topic to discuss, I do not see obvious way for now... Thanks! Vadim Kristian Nielsen wrote: > Percona <launch...@percona.com> writes: > >> Percona has proposed merging lp:~maria-captains/maria/maria-xtradb into >> lp:maria. >> >> Requested reviews: >> Maria-captains (maria-captains) >> >> Proposal to merge replacement InnoDB->XtraDB > > Thanks a lot for your efforts in this! > > I branched the tree and took a look. There are a couple of issues that I think > need to be resolved before we can merge it into MariaDB. I have some questions > below, but please don't hesitate to ask me for any kind of help needed to move > this forward. > >> === modified file 'storage/innobase/include/sync0rw.h' >> --- storage/innobase/include/sync0rw.h 2008-02-19 16:44:09 +0000 >> +++ storage/innobase/include/sync0rw.h 2009-03-31 04:19:17 +0000 > >> +#ifndef INNODB_RW_LOCKS_USE_ATOMICS >> +#error INNODB_RW_LOCKS_USE_ATOMICS is not defined. Do you use enough new >> GCC or compatibles? >> +#error Or do you use exact options for CFLAGS? >> +#error e.g. (for x86_32): "-m32 -march=i586 -mtune=i686" >> +#error e.g. (for Sparc_64): "-m64 -mcpu=v9" >> +#error Otherwise, this build may be slower than normal version. >> +#endif >> + > > My attempt to build (BUILD/compile-pentium64-max) failed with this > error. There were also other build errors (I assume places where the > atomics-using code has not been extended with a part that works without the > availability of atomics). > > The reason is that in the MariaDB tree, HAVE_GCC_ATOMIC_BUILTINS is disabled, > which caused XtraDB to disable INNODB_RW_LOCKS_USE_ATOMICS, which triggers the > above error. > > I think I understand why this makes sense for Percona, after all using these > better synchronisation primitives is part of the reason for using the Percona > server in the first place. > > Can you tell me if Percona has decided not to maintain XtraDB working without > the availability of atomic operations? Or if it is just an oversight? > > I need to discuss with other MariaDB people whether XtraDB for MariaDB should > be maintained working without the atomic operations (if so, we should of > course be willing to do the work/effort required). > > So, any thoughts about the best way to deal with this? Should the above #error > be removed and XtraDB extended to work without atomics in the MariaDB tree? > And is this something Percona wants to do, or should I look into it? > > Also, Sergei Golubchik told me that HAVE_GCC_ATOMIC_BUILTINS is for > my_atomic_ops, and InnoDB/XtraDB shouldn't really be using it. But I need to > look more into the code to understand what the problem is, if any. > >> === added directory 'storage/innobase/mysql-test' > >> === added directory 'storage/innobase/mysql-test/patches' > > When I ran the test suite, I got test failures in test main.innodb. > > I see that the patch contains patches for main MySQL test cases in > mysql-test/t/*.test, and also seems to add separate test cases in the > storage/innobase/mysql-test/ directory. > > Do you know what the status is of these test suite modifications? Do the > patches need to be applied to the existing test suite, and/or should the extra > test cases be used to add to/overwrite the existing tests? > > We would need to get the test suite to run without problems before > merging. Does Percona run the test suite with no failures? Can you suggest > which directions I should work in to solve the test failures? Ie. I'm unsure > to what extent the extra test cases/patches have already been applied in main > MySQL sources, and whether failures are expected or are just due to not being > adapted for current MariaDB source changes. > > Any help with the above would be great. I plan to continue working with you on > this so we can get it merged without unnecessary delays. > > - Kristian. > -- Vadim Tkachenko, CTO Percona Inc. ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403 MySQL Performance Blog - http://www.mysqlperformanceblog.com MySQL Consulting http://www.percona.com/ Attend the 2009 Percona Performance Conference April 22-23 - http://conferences.percona.com/ _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
