public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Benjamin A. Beasley <code@musicinmybrain.net>
To: git-commits@fedoraproject.org
Subject: [rpms/uv] rawhide: Avoid OOM on builders with relatively little total memory
Date: Sat, 18 Jul 2026 07:17:43 GMT [thread overview]
Message-ID: <178435906387.1.3907142208998676167.rpms-uv-9df354a5935d@fedoraproject.org> (raw)
A new commit has been pushed.
Repo : rpms/uv
Branch : rawhide
Commit : 9df354a5935d9f5979e6a7f9f1f98b33500861a6
Author : Benjamin A. Beasley <code@musicinmybrain.net>
Date : 2026-07-18T08:16:51+01:00
Stats : +13/-9 in 1 file(s)
URL : https://src.fedoraproject.org/rpms/uv/c/9df354a5935d9f5979e6a7f9f1f98b33500861a6?branch=rawhide
Log:
Avoid OOM on builders with relatively little total memory
---
diff --git a/uv.spec b/uv.spec
index b5de105..6ba0a89 100644
--- a/uv.spec
+++ b/uv.spec
@@ -168,15 +168,19 @@ ExcludeArch: %{ix86}
# https://doc.rust-lang.org/rustc/codegen-options/index.html#debuginfo
%global rustflags_debuginfo 1
-# As a separate limitation, memory exhaustion can occur on builders with very
-# many CPUs. Typical workspace crates peak out at 2-4 GB per rustc invocation.
-# The uv crate needs much more memory to compile and link, but in practice it
-# is also compiled alone after all the other crates have finished, so it does
-# not need to influence (and does not benefit from) this setting. This setting
-# does not necessarily have to reflect the maximum memory required to compile a
-# workspace crate; keeping it well above the average suffices in practice on
-# many-core systems. Increase as needed.
-%global _smp_tasksize_proc 4096
+# As a separate limitation, memory exhaustion (OOM) can occur during parallel
+# portions of the build.
+# - Because very many workspace crates can be built in parallel, builders with
+# a very large number of CPUs may OOM. Typical workspace crates peak out at
+# roughly 2–4 GB per rustc process.
+# - The uv crate needs much more memory to compile and link, at least 8 GB, and
+# when building the tests we may be building bin and lib versions at the same
+# time, along with the it (integration test) crate, which is also rather
+# large. This is a problem for “low memory” builders (<20 GB or so).
+# Unfortunately, this means that we need to scale the memory per task based on
+# the memory requirements of the top-level uv crate in order to avoid OOM on
+# all kinds of builders.
+%global _smp_tasksize_proc 10240
# Compilation may fail on builders with very many cores (e.g. 192 cores) due to
# “too many open files.” Try to keep the files/core ratio from getting too low.
reply other threads:[~2026-07-18 7:17 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178435906387.1.3907142208998676167.rpms-uv-9df354a5935d@fedoraproject.org \
--to=code@musicinmybrain.net \
--cc=git-commits@fedoraproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox