Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support shared library build of Redpanda #10220

Merged
merged 3 commits into from
Apr 20, 2023
Merged

Conversation

dotnwat
Copy link
Member

@dotnwat dotnwat commented Apr 20, 2023

Final set of changes needed to enable shared library builds.

  • Moves recovery services from cloud storage into cluster
  • Compiles (but does not move) archival into cluster (deep dependencies)
  • Fixes a few dependency issues in the cmake build

Usage: task rp:build BUILD_TYPE=debug BUILD_SHARED_LIBS=on

See it in action: The CI run for this PR builds with static libraries, as normal. The CI run for this vtools sister PR (https://github.com/redpanda-data/vtools/pull/1726) turns on shared libraries by default for debug builds (in both CI and for normal users).

Once this PR and https://github.com/redpanda-data/vtools/pull/1726 merge users will need need to reconfigure / rebuild all of the redpanda deps the next time they update vtools.

Before

[nwatkins@panda redpanda]$ du -sh vbuild/debug/clang
134G    vbuild/debug/clang
[nwatkins@panda redpanda]$ du -sh vbuild/debug/clang/{bin,lib,rp_deps_install}
108G    vbuild/debug/clang/bin
5.8G    vbuild/debug/clang/lib
1.9G    vbuild/debug/clang/rp_deps_install

After

[nwatkins@panda redpanda]$ du -sh vbuild/debug/clang
23G     vbuild/debug/clang
[nwatkins@panda redpanda]$ du -sh vbuild/debug/clang/{bin,lib,rp_deps_install}
2.5G    vbuild/debug/clang/bin
3.0G    vbuild/debug/clang/lib
1.2G    vbuild/debug/clang/rp_deps_install

Reducing the size of the bin directory has a lot of impact: all of the data in there needs to be generated, and in the shared library build we are generating roughly 43x less data and eliminating the linking costs that go into producing that much data. Anecdotally I see that compiling (not linking as was the case before) application.cc and admin_server.cc are now the bottlenecks.

For those of you that have tried mold but found that it did not work well with the static library build, it may work much better now. Yet to be verified.

Backports Required

  • none - not a bug fix
  • none - this is a backport
  • none - issue does not exist in previous branches
  • none - papercut/not impactful enough to backport
  • v23.1.x
  • v22.3.x
  • v22.2.x

Release Notes

  • none

The partition recovery manager and topic recovery service are moved from
cloud storage into the cluster library. The recovery services make sense
to be outside the leaner cloud storage library, and importantly, it
breaks a circular dependency between the two subsystems.

Signed-off-by: Noah Watkins <[email protected]>
The archival and cluster libraries are intertwined to the point that
separating them to resolve a circular dependency has proved quite
difficult. On the other hand, compiling archival into the cluster
library itself fully resolves the issue.

This commit does not move any files, but merely changes the build system
to reflect the new compilation strategy. This is useful because there
are many inflight changes that would incur a large cost due to a file
move and namespace changes. Future clean up should address this
temporary layout.

Signed-off-by: Noah Watkins <[email protected]>
Primarily this addresses missing dependencies that are required in a
shared library build.

Signed-off-by: Noah Watkins <[email protected]>
Copy link
Contributor

@rockwotj rockwotj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoot! This is great 👍

I have a couple questions mostly to make sure I understand.

I was reading your dialogue with Travis about absl::Hash's seed. Did we want to add a test to verify the hash is consistent across .so in this PR or did we want to punt that to another?

src/v/archival/CMakeLists.txt Show resolved Hide resolved
@dotnwat
Copy link
Member Author

dotnwat commented Apr 20, 2023

Did we want to add a test to verify the hash is consistent across .so in this PR or did we want to punt that to another?

I think we should add it separately. Our release/production builds are still static linking. #10231

Copy link
Contributor

@andrwng andrwng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dotnwat dotnwat merged commit 56004dd into redpanda-data:dev Apr 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants