-
Notifications
You must be signed in to change notification settings - Fork 884
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
Slab allocator panics if unpack RAM is manually set too low (or machine has < 32MB of RAM). #2771
Comments
@kinnison The latest beta test result. |
After removing the environment variable |
I think this suggests there'll be some tweaking to be done on how we handle forced lower-RAM scenarios, but since |
rustup update
One possible fix for this could be to ensure that the minimum specified RAM limit is not below the total of 1 slab of each size. |
Thanks. Please keep the good work. |
@kinnison there is already a check for minimum size > sum of slabs : the threaded pool startup allocates one of each pool to ensure that there is no chance of starvation due to bad workload patterns. This panic is in fact exactly that check. We can make it prettier sure, but theres no actual fault here. |
Mmm, in my view this kind of check should either have happened right at the start, or it should be soft - i.e. too small a limit should be bumped up to the functional minimum and a warning issued. |
Sure, no in principle disagreement there. It is at the start FWIW: https://github.com/rust-lang/rustup/blob/master/src/diskio/threaded.rs#L167 |
Problem
panic when run
rustup update
using 1.24.2 beta versionSteps
rustup update
Possible Solution(s)
No idea.
Notes
The text was updated successfully, but these errors were encountered: