maria-discuss team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Laurynas!

On Feb 07, Laurynas Biveinis wrote:
> Sergei, Colin, MariaDB -
> 
> >> >> "XtraDB storage engine was upgraded to the 5.6 version. Now one can
> >> >> use XtraDB with MariaDB 10.0. Unlike MariaDB 5.5, in 10.0 XtraDB is
> >> >> not the default engine, the default is InnoDB, and XtraDB is
> >> >> available as a dynamic plugin"
> >> >>
> >> > XtraDB simply does not compile on all our builders - Percona has
> >> > introduced patches that use CPU atomic ops and didn't implement a
> >> > fallback for setups where they are not available (like all the rest
> >> > of the code does, including InnoDB).
> >>
> >> Have we reported bugs upstream?
> >
> > https://bugs.launchpad.net/bugs/1276963
> >
> >> Do we plan on fixing this ourselves if upstream doesn't?
> >
> > Not at the moment - that code is quite complex.
> 
> In the bug report you mention RHEL 5 with GCC 4.1.2 (presumably on 32
> bits). This is one of our supported platforms too, and we solve this
> by adding -march=i686 which makes the necessary builtins available.
> Would that work for you?

That kind of worked. XtraDB compiled.
But query_response_time failed with "unable to find a register to spill
in class 'GENERAL_REGS'".

Still better than before. In the worst case, I'll enable XtraDB and
disable query_response_time plugin.

> We have another platform-specific addition: thread-local storage
> implemented by __thread GCC keyword, which is GNU specific. This is

Yes, I've noticed. It caused lots of valgrind warnings because __thread
implementation uses __tls_get_addr() in glibc and that allocated memory
which valgrind didn't see being freed. I've added a suppression for it.

> used to implement the relative XtraDB thread priorities:
> http://www.percona.com/doc/percona-server/5.6/performance/xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads.html#relative-thread-scheduling-priorities-for-xtradb.
> On non-Linux plaftorms the feature should compile but should be
> silently disabled, that is, setting innodb_sched_priority_* options
> are no-ops. How big is this an issue for you?

Besides this valgrind warning there were no issues so far.

Or do you mean a different behavior of innodb_sched_priority_* options?
I think it's ok for us, if it's ok for you :)

Regards,
Sergei