-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Import rust-installer & adjust compression settings #108534
Conversation
|
@bors r+ |
@bors r- I want to check locally with dev-static |
@bors try |
⌛ Trying commit 48af38f with merge 9060c7f5f9eae7cc9697bef19898ba1e38b2ee56... |
☀️ Try build successful - checks-actions |
Baseline install of nightly-2023-02-27 takes 53 MB with Wall-time for installation seems to take roughly the same amount of time with the minimum settings (6.9s before, 6.4s now). When not constraining I/O threads or memory, 7.2s before, 6.5s now. Ultimately this all seems fairly reasonable so going to go ahead and move ahead, if we run into trouble we can back it out. @bors r=pietroalbini |
…troalbini Bump rust-installer This brings in rust-lang/rust-installer#123, which enables a larger compression window (8 -> 64MB) amongst other changes to the xz compression settings. The net effect should be smaller compressed tarballs which will decrease bandwidth usage for static.rust-lang.org, download times, and decompression time. This comes at the cost of higher baseline requirements for running rustup to use these files, which we believe should be largely acceptable (running rustc is likely to use at least this much memory) but if we get specific reports we may explore options to decrease impact (e.g., using the gzip tarballs automatically in rustup).
@bors rollup=never master: my rollup which included this pr: this is like more then factor 10 for just this tarball? Just compression takes almost half an hours now (for that one artifact!) |
Hm, probably due to dropping the thread count. I'll update to avoid that. |
@bors r- |
@bors try |
d4e6306
to
7040337
Compare
@bors r=pietroalbini rollup=never |
📌 Commit 70403375ae66f7e480c0ba616df5f1773895bb02 has been approved by It is now in the queue for this repository. |
⌛ Testing commit 70403375ae66f7e480c0ba616df5f1773895bb02 with merge e4666f4fe99c67dea739cac0d674f59ce0fe75ca... |
💔 Test failed - checks-actions |
This brings in rust-lang/rust-installer#123, which enables a larger compression window (8 -> 64MB) amongst other changes to the xz compression settings. The net effect should be smaller compressed tarballs which will decrease bandwidth usage for static.rust-lang.org, download times, and decompression time. This comes at the cost of higher baseline requirements for running rustup to use these files, which we believe should be largely acceptable (running rustc is likely to use at least this much memory) but if we get specific reports we may explore options to decrease impact (e.g., using the gzip tarballs automatically in rustup).
This moves the rust-installer code to be directly hosted in rust-lang/rust, since it's not used elsewhere and this makes it easier to make and review changes without needing a separate upstream commit.
Limit to 3 threads for 32-bit platforms, otherwise we use 6 threads. This avoids exceeding the amount of memory we can allocate on a 32-bit platform.
7040337
to
dabafb4
Compare
@bors r=pietroalbini rollup=never |
This comment has been minimized.
This comment has been minimized.
☀️ Test successful - checks-actions |
Finished benchmarking commit (60445fd): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
…ark-Simulacrum Add `dist.compression-profile` option to control compression speed PR rust-lang#108534 reduced the size of compressed archives, but (as expected) it also resulted in way longer compression times and memory usage during compression. It's desirable to keep status quo (smaller archives but more CI usage), but it should also be configurable so that downstream users don't have to waste that much time on CI. As a data point, this resulted in doubling the time of Ferrocene's dist jobs, and required us to increase the RAM allocation for one of such jobs. This PR adds a new `config.toml` setting, `dist.compression-profile`. The values can be: * `fast`: equivalent to the gzip and xz preset of "1" * `balanced`: equivalent to the gzip and xz preset of "6" (the CLI defaults as far as I'm aware) * `best`: equivalent to the gzip present of "9", and our custom xz profile The default has also been moved back to `balanced`, to try and avoid the compression time regression for downstream users. I don't feel too strongly on the default, and I'm open to changing it. Also, for the `best` profile the XZ settings do not match the "9" preset used by the CLI, and it might be confusing. Should we create a `custom-rustc-ci`/`ultra` profile for that? r? `@Mark-Simulacrum`
…ark-Simulacrum Add `dist.compression-profile` option to control compression speed PR rust-lang#108534 reduced the size of compressed archives, but (as expected) it also resulted in way longer compression times and memory usage during compression. It's desirable to keep status quo (smaller archives but more CI usage), but it should also be configurable so that downstream users don't have to waste that much time on CI. As a data point, this resulted in doubling the time of Ferrocene's dist jobs, and required us to increase the RAM allocation for one of such jobs. This PR adds a new `config.toml` setting, `dist.compression-profile`. The values can be: * `fast`: equivalent to the gzip and xz preset of "1" * `balanced`: equivalent to the gzip and xz preset of "6" (the CLI defaults as far as I'm aware) * `best`: equivalent to the gzip present of "9", and our custom xz profile The default has also been moved back to `balanced`, to try and avoid the compression time regression for downstream users. I don't feel too strongly on the default, and I'm open to changing it. Also, for the `best` profile the XZ settings do not match the "9" preset used by the CLI, and it might be confusing. Should we create a `custom-rustc-ci`/`ultra` profile for that? r? ``@Mark-Simulacrum``
This comment strike back: while working on #112884 i found out that this flag set |
This brings in rust-lang/rust-installer#123, which enables a larger compression window (8 -> 64MB) amongst other changes to the xz compression settings. The net effect should be smaller compressed tarballs which will decrease bandwidth usage for
static.rust-lang.org, download times, and decompression time.
This comes at the cost of higher baseline requirements for running rustup to use these files, which we believe should be largely acceptable (running rustc is likely to use at least this much memory) but if we get specific reports we may explore options to decrease impact (e.g., using the gzip tarballs automatically in rustup).
To simplify iteration on compression settings this also imports the rust-lang/rust-installer submodule, it is now hosted fully inside rust-lang/rust. Once we land this I'll file a followup to add a note to that repo and we can subsequently archive it.
--
CI times for dist-x86_64-linux builds: