maria-discuss team mailing list archive

[Laurynas Biveinis <laurynas.biveinis@xxxxxxxxx>]

Sergei -

>> >> > 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.


Pushing down -march=i686 to xtradb dir only would work around this,
wouldn't it? (our proper fix for 1276963 is likely to contain that. It
would add the flag to the top level CMake and to the innodb subdir.
The former is for us, the latter is for folks who take innodb only,
i.e. you. This would work because core and InnoDB atomic builtin tests
are independent in CMake currently).

I tried to reproduce the compiler failure on our Jenkins, but it
didn't show up: http://jenkins.percona.com/job/mariadb-10.0-trunk/3/,
although the CentOS 5 slaves failed due to missing dependencies, and
our build flags used are probably different from yours.


>> 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.


Interesting, I haven't noticed this before, will check.


>> 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?
>
> 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 :)


Yes, I mean the different behavior. It's OK for us because the
behavior is correct on all the platforms we support, but it wouldn't
be OK on some of the platforms you support, would it?


-- 
Laurynas