From 9b542cd360117fe73d1369326614bb6df359f0b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lukas=20Br=C3=BCbach?= <44814898+BruebachL@users.noreply.github.com> Date: Sat, 7 Nov 2026 10:12:45 +0100 Subject: [PATCH] [CI] Keep the measured ccache bounds instead of raising them Steady-state master shows Arch at 90.1% and Debian 13 at 96.75% per-run hits on the existing 850M/800M bounds. The 75%/82% that motivated the increase were warming runs right after the -g1 switch invalidated the cache, not thrashing. Keep the bounds, keep the macOS 14 cache drop. --- .github/workflows/desktop-build.yml | 43 +++++++++++++++-------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/.github/workflows/desktop-build.yml b/.github/workflows/desktop-build.yml index eca583be3..d33a8c2ea 100644 --- a/.github/workflows/desktop-build.yml +++ b/.github/workflows/desktop-build.yml @@ -150,7 +150,7 @@ jobs: allow-failure: yes package: skip # We are packaged in Arch already debug_test: yes # see the note on Fedora 45 below - ccache_size: 1200M # Debug plus the suite: 680 MB working set at -g1; 850M thrashed + ccache_size: 850M # Debug plus the suite: 680 MB working set at -g1 - distro: Servatrice_Debian version: 12 @@ -165,7 +165,7 @@ jobs: version: 13 package: DEB - ccache_size: 1050M # Release plus the suite: 625 MB working set at -g1; 800M thrashed + ccache_size: 800M # Release plus the suite: 625 MB working set at -g1 # The single Fedora leg used to build Debug for the suite and Release for the # package in one job (measured on Fedora 44: 30.8 min, the only leg slower than @@ -225,33 +225,34 @@ jobs: # whole configuration therefore buys almost nothing, and the quota goes to fewer legs # at a size that holds one: # - # Arch Debug + suite 680 MB working set 1200M - # Debian 13 Release + suite 625 MB 1050M + # Arch Debug + suite 680 MB working set 850M + # Debian 13 Release + suite 625 MB 800M # Fedora 45 debug Debug + suite 660 MB 850M # Fedora 45 release Release + package 614 MB 800M # - # That is about 3.9 GB of bounds, and with the fixed entries above (about 4.4 GB) it - # puts the quota at roughly 8.3 GB of 10 - so only legs worth their share get one. A - # leg keeps no cache when it duplicates another leg's coverage (Ubuntu 26.04 behind - # Debian 13's Release + suite; macOS 15 and macOS 27 Debug behind macOS 14) or - # finishes well inside the Windows leg (Servatrice covers the server alone in 4.7 - # min). All three macOS legs run cold: macOS 14's 800M cache served 42% and saved - # about 32s on a 20 min leg that is already shorter than Windows, so that bound is - # better spent here. The four Linux legs that stay compile the client on the - # toolchains a change can break and are the ones a cache shortens by the most. + # That is 3.3 GB of bounds, and with the fixed entries above (about 4.4 GB) it puts + # the quota at roughly 7.7 GB of 10 - so only legs worth their share get one. A leg + # keeps no cache when it duplicates another leg's coverage (Ubuntu 26.04 behind + # Debian 13's Release + suite; the macOS legs behind the Linux ones) or finishes well + # inside the Windows leg (Servatrice covers the server alone in 4.7 min). A macOS + # cache served 42% and saved about 32s on a 20 min leg that is already shorter than + # Windows, so that bound is better spent here. The four Linux legs that stay compile + # the client on the toolchains a change can break and are the ones a cache shortens + # by the most. # Measured job totals on master 2026-11-04 also show the ceiling this leaves: # Windows 10 is 29.5 min and compiles for 23.7 of it with no compiler cache at all, so # Windows still sets the pull-request wall clock no matter how warm these legs are # (see build-vcpkg). # - # Measured on master 2026-11-06: Fedora 45 debug/release hit 99.5% at 80% full, while - # Arch served 75% at 96% full and Debian 13 82% at 96% - both evict entries they need. - # A cold 3G run on 2026-11-07 measured one configuration at 680 MB (Arch) and 625 MB - # (Debian 13), so the old 850M/800M bounds already exceeded the working set. They - # thrashed because commit-to-commit churn filled the ~170 MB of slack and evicted live - # entries. The bounds above leave 520/425 MB for that churn, so the working set stays - # resident across compiler and image updates. The sanitize leg's 1.2G cache is - # nightly-only now, and macOS 14's 800M is dropped; that is what funds the increase. + # Steady-state master data corrected this on 2026-11-07: Arch 90.1% and Debian 13 + # 96.75% per-run hits at the 850M/800M bounds, Fedora 45 debug 99.18% and release + # 99.2%. The 75%/82% seen the day before were warming runs - the -g1 switch had + # invalidated the cache one commit earlier - not thrashing at the bound. A cold 3G + # run on the same day measured one configuration at 680 MB (Arch) and 625 MB + # (Debian 13), so those bounds already hold the working set with ~170 MB of slack for + # commit-to-commit churn, and raising them buys hit rate the numbers do not show a + # need for. macOS 14's 800M entry is dropped because persistence buys 32s there; the + # quota stays free for the legs whose bounds would actually miss. # # Re-add a leg only with a bound that holds its whole configuration: a smaller one is # worse than none.