ucx should depend on libnuma #112
Comments
|
It comes from the system |
|
Separately we have asked upstream to separate this into a runtime loadable library ( openucx/ucx#4570 ), which would make this optional from the end user's perspective |
|
As I said, it is not always provided by the base system. I have a Docker image where I had to install |
|
Right, please let me clarify, it needs to be installed from the system. Am aware Docker images don't always have this. One can |
|
But why does it "need" to be installed from the system, even though conda-forge provides it? |
|
@pitrou Thank you for raising the question. The I am under the same impression as @jakirkham that @chrisburr @ocefpaf Any chance to clarify our potential misunderstanding here, since you raised/approved conda-forge/staged-recipes#21176? cc: @conda-forge/core |
|
I have some machines that should report 2 numa nodes (threadripper gen 2) if I configure them to do so in bios. I could test the hypothesis that numa should be build in accordance to the system if we can come up with a good hypothesis. |
I honestly have no idea. That said, the official documentation says that "the libnuma binary interface is supposed to stay binary compatible" without any reference to build-time knobs that would affect the ABI. Perhaps you can ask the question on that project's issue tracker? |
|
@lidavidm FYI. |
|
libnuma (via numactl) appears to be one of the CDT packages: https://conda-forge.org/docs/maintainer/knowledge_base.html#core-dependency-tree-packages-cdts So it is a repackaged CentOS library. Since the Linux kernel at least tries to not break userspace, presumably that is fine (it just may be an old version of libnuma). But I'm not familiar with libnuma specifically. I suppose y'all already had that discussion at rapidsai/ucx-py#790 so there's nothing new here. |
|
Thank you for linking to that discussion. Should we continue this chain there? |
|
I have been testing |
|
If testing shows it works, agree it makes sense to add this as a dependency |
|
It seems that UCX 1.14 is going to be released soon, RC1 was tagged a couple days ago and feedback so far has been positive from other users. If there are no objections, I propose waiting for the 1.14.0 release and add |
|
That was going to be my suggestion as well Do you want to test that release first? Or should we go ahead and package it here with that change? Should note if we do the latter and it has problems, we can always pull the package and rebuild with the system library Edit: Maybe a middle option would be to share the builds on CI in the PR. Then test them. If they look good, merge the release PR |
Please note that there's no release yet, I've tested RC1 and it seems good, but I don't think we want to release conda-forge RC packages so we can wait until official release. I normally test all RCs, so hopefully when the release is out we can then just package it, no need for additional testing (at least from the RAPIDS side).
I'm ok with that also, when we have a conda-forge package I could test it just to ensure changes from #111 plus |
Yep am aware
Ok
Then let's plan on doing that |
|
One other observation here, currently
Edit: The PR noted in 3 is merged. So we should be good to go with option 3. |
|
We are adding |
Solution to issue cannot be found in the documentation.
Issue
The UCX shared libraries depend on symbols from libnuma, however, libnuma is not automatically installed with UCX, and it is not always provided by the base system.
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: