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
orc::InProcessMemoryMapper makes too many memory mappings #63236
Comments
@llvm/issue-subscribers-orcjit |
Within the I think the OS should be able to coalesce adjacent mappings. If that's the case then a simple next step would be to allocate text pages from the bottom of the address space and data pages from the top. We'll get some fragmentation due to the mix of |
Hi! This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:
For more instructions on how to submit a patch to LLVM, see our documentation. If you have any further questions about this issue, don't hesitate to ask via a comment on this Github issue. @llvm/issue-subscribers-good-first-issue |
Something like that, I was thinking of doing something like 4mb chunks that you write text from top to the bottom and data from bottom to top. |
@llvm/issue-subscribers-julialang |
Hi @gbaraldi! I am new to LLVM and would like to work on this issue. Can you please assign it to me. |
@Sh0g0-1758 feel free to work on it, but it won't be officially assigned to you. If you come up with a solution you can open a PR and mention this issue |
First seen in JuliaLang/julia#49745, but to summarize, InProcessMemoryMapper calls
mprotect
many many times onmmap
ed memory, so many times that for a non trivial workload we go past/proc/sys/vm/max_map_count
leading to aENOMEM
error.I haven't created a non julia reproducer but it should be possible.
The text was updated successfully, but these errors were encountered: