HDDS-10477. Make Rocksdb tools native lib compatible with all chipset with the same arch#6341
Conversation
…s within the arch
|
|
||
| cmake_minimum_required(VERSION 2.8) | ||
| add_definitions(-D_GLIBCXX_USE_CXX11_ABI=0) | ||
| set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC") |
There was a problem hiding this comment.
Why no optimization at all? This is different that specifying the instruction sets. Can you look into add_compile_options(-msse2) ? I am not sure no optimization == chipset instructions to be used.
There was a problem hiding this comment.
I am not really aware of this, but let me check this out and get back on this.
|
should we force USE_SSE=0 or -DFORCE_SSE42=OFF ? |
|
|
SSE2 is pretty common based on the documentation in that makefile |
|
@swamirishi the main issue is due to the use of AVX related instructions, we can skip those explicitly and we can target an instruction set that is more common. |
| <arg line="${project.build.directory}/rocksdb/rocksdb-${rocksdb.version}"/> | ||
| </exec> | ||
| <exec executable="make" dir="${project.build.directory}/rocksdb/rocksdb-${rocksdb.version}" failonerror="true"> | ||
| <arg line="PORTABLE=1"/> |
There was a problem hiding this comment.
RocksDB does not use PORTABLE=0 so there is still some information missing as to what is the build setup.
For now pushing this in makes sense as we are seeing crashes for missing AVX4 but we still need to continue looking into what is the lowest common set of instruction set the build should support or at least quantify the performance impact. @swamirishi can you open a follow up Jira? Also, how was this change tested?
There was a problem hiding this comment.
The .so from the publicly distributed rocksdbjni-7.7.3.jar doesn't seem to be AVX or AVX2 optimized:
$ elfx86exts librocksdbjni-linux64.so
File format and CPU architecture: Elf, X86_64
MODE64 (call)
CMOV (cmovbe)
SSE1 (movups)
SSE2 (movdqa)
BMI (tzcnt)
BMI2 (shlx)
Instruction set extensions used: BMI, BMI2, CMOV, MODE64, SSE1, SSE2
CPU Generation: Haswell|
@swamirishi we can merge this in once you specify the testing done for this. |
I tested out this particular patch by building the code in an environment which supports avx2. I built the shared library and tried to load the library on another machine which doesn't support this instruction set without the flag PORTABLE=1 and with the flag PORTABLE=1.
The second time the load succeeded. |
Yup fyi https://github.com/facebook/rocksdb/blob/v7.7.3/CMakeLists.txt#L252-L277 |
… with the same arch (apache#6341)
… with the same arch (apache#6341) (cherry picked from commit e3a7224)
… with the same arch (apache#6341) (cherry picked from commit e3a7224)
… with the same arch (apache#6341) (cherry picked from commit e3a7224)
… all chipset with the same arch (apache#6341) (cherry picked from commit e3a7224) Change-Id: If5ff48cc5d38f7a0256015e5731675be8a4ed9a4


What changes were proposed in this pull request?
While building rocksdb tools lib, makefile of rocksdb adds native optmization gcc flags when compiling rocksdb code. This makes the built code incompatible with other chipsets, where it fails with illegal instruction when loading the native lib on ozone manager jvm.
Setting PORTABLE=1 while building rocksdb tools will fix this particular issue, and also adding -O0 flag while compiling jni on ozone will prevent the same on ozone jnilib side.
https://github.com/facebook/rocksdb/blob/v7.7.3/INSTALL.md#:~:text=By%20default%20the,make%20static_lib.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-10477
How was this patch tested?
Successful build and checking the native lib manually on various instance