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