memory-leaks

killing-time.org (25856B)

---

 On November 19 2024, LDLC's off-brand SSD died on me.  RIP.
 Re-installed Tumbleweed on the replacement (Kingston SA400S3) on
 November 28.
 
 Since then, I have been getting uncannily reproducible stuttering and
 frame drops (60↘40±10) in Hades Ⅱ when moving toward effect- or
 particle-heavy sub-areas of the hub rooms (e.g. toward the Cauldron at
 the Crossroads, or toward the Silver Pool in the Training Grounds).
 No idea WTF, those areas ran fine before.
 
 - "High" graphics setting at native 1920×1080 resolution.
   - Tried "Low" graphics, lowered resolution, disabled vsync, switched
     to Windowed mode: symptoms persist.
 - Proton Experimental.
   - Tried a couple of old Proton versions: symptoms persist.
 - Reinstalled game & nuked everything under
   - =~/.cache/mesa_shader_cache*=
   - =~/.cache/radv_builtin_shaders*=
   - =~/.config/unity3d=
   - =~/.local/share/Steam=
   - =~/.local/share/vulkan/=
   - =~/.steam*=
   in case "stale shaders" were to blame or something.
 - Tumbleweed/Plasma/Wayland session.
   - Tried X11: symptoms persist.
 - Reducing noise with
   - ~balooctl6 suspend~
   - ~swapoff -a~ (RAM nowhere near exhausted)
 
 Well then.
 * CPU frequency scaling?
 (Hey 👋 A warning: this was the first rabbit hole I burrowed into.
 Spoiler alert: nothing I learned here solved the problem.  Chronicled
 the journey anyway since I wandered through interesting spots)
 
 The Plasma "Power Management" tray widget says "Power Profile" is "Not
 available".  Not sure whether that was the case with the previous
 installation; maybe I had something configured or installed to enable
 this?
 
 Internet says "install and enable power-profiles-daemon", but
 that is already on:
 
 #+begin_example
 $ systemctl status power-profiles-daemon.service
 ● power-profiles-daemon.service - Power Profiles daemon
      Loaded: loaded (/usr/lib/systemd/system/power-profiles-daemon.service; disabled; preset: disabled)
      Active: active (running) since Sun 2024-12-01 11:46:32 CET; 45min ago
  Invocation: b2545a02bc9642b7aeb5f370e8b50e7c
    Main PID: 2289 (power-profiles-)
       Tasks: 4 (limit: 18320)
         CPU: 52ms
      CGroup: /system.slice/power-profiles-daemon.service
              └─2289 /usr/libexec/power-profiles-daemon
 #+end_example
 
 But:
 
 #+begin_example
 $ powerprofilesctl
 ,* balanced:
     PlatformDriver:     placeholder
 
   power-saver:
     PlatformDriver:     placeholder
 #+end_example
 
 Internet says I am missing the right scaling driver, and sounds very
 keen on enabling =amd_pstate=, which I do not seem to have available.
 =/proc/config.gz= suggests the kernel configuration supports it, but
 =cpupower= does not know about it:
 
 #+begin_example
 $ zcat /proc/config.gz | grep -i pstate
 CONFIG_X86_INTEL_PSTATE=y
 CONFIG_X86_AMD_PSTATE=y
 CONFIG_X86_AMD_PSTATE_DEFAULT_MODE=3
 # CONFIG_X86_AMD_PSTATE_UT is not set
 
 $ cpupower frequency-info
 analyzing CPU 5:
   driver: acpi-cpufreq
   CPUs which run at the same hardware frequency: 5
   CPUs which need to have their frequency coordinated by software: 5
   maximum transition latency:  Cannot determine or is not supported.
   hardware limits: 1.40 GHz - 3.70 GHz
   available frequency steps:  3.70 GHz, 1.70 GHz, 1.40 GHz
   available cpufreq governors: ondemand performance schedutil
   current policy: frequency should be within 1.40 GHz and 3.70 GHz.
                   The governor "schedutil" may decide which speed to use
                   within this range.
   current CPU frequency: Unable to call hardware
   current CPU frequency: 3.30 GHz (asserted by call to kernel)
   boost state support:
     Supported: yes
     Active: no
 #+end_example
 
 =dmesg= offers:
 
 #+begin_example
 $ sudo dmesg -H
 […] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
 #+end_example
 
 Though:
 
 #+begin_example
 $ lscpu | grep -i cppc
 Flags:                                […] cppc […]
 #+end_example
 
 So ACPI problem?  Lots of posts mention =amd_= parameters on the
 kernel command-line, but AFAIU those posts are stale with newer
 kernels (6.11 as of this writing) which automatically (attempt to)
 load the =amd_pstate= driver.
 
 Went through the UEFI menu and found nothing related to ACPI or
 [[https://forum.level1techs.com/t/amd-p-state-driver/197885/24][X2APIC]].  Skeptical of UEFI settings anyway, since I did not change
 them between the old and new installations.
 
 {{{narrator(Some time later)}}}
 
 Probably not ACPI, =dmesg= is choke full of ACPI noise.  OTOH, using
 some diagnosis methods from [[https://bugzilla.kernel.org/show_bug.cgi?id=218171][this kernel bug report]]:
 
 #+begin_example
 $ find /sys/devices -name '*cppc*'
 🦗
 #+end_example
 
 (~acpidump ; acpixtract ; iasl ; grep -i cpc *.dsl~ also yields 🦗,
 but =iasl= complains about "unresolved" "control methods", so 🤷)
 
 {{{narrator(Some time later)}}}
 
 [[https://wiki.archlinux.org/title/CPU_frequency_scaling#amd_pstate][ArchWiki]] does say "Change /Enable CPPC/ […] from /Auto/ to /Enabled/".
 My UEFI menu tucks that under /Overclocking → Advanced CPU
 Configuration → AMD CBS → CPPC CTRL/.  That change *does* convince
 Linux to enable =amd_pstate=; going over the previous tests in reverse
 order:
 
 #+begin_example
 $ [… acpidump && acpixtract && iasl … ] && grep -i cpc *.dsl
 ssdt1.dsl:        Name (_CPC, Package (0x17)  // _CPC: Continuous Performance Control
 [… repeats 12 times …]
 
 $ find /sys/devices -name '*cppc*' -o -name '*pstate*' | tr -s '[:digit:]' N | sort -u
 /sys/devices/system/cpu/amd_pstate
 /sys/devices/system/cpu/cpufreq/policyN/amd_pstate_highest_perf
 /sys/devices/system/cpu/cpufreq/policyN/amd_pstate_hw_prefcore
 /sys/devices/system/cpu/cpufreq/policyN/amd_pstate_lowest_nonlinear_freq
 /sys/devices/system/cpu/cpufreq/policyN/amd_pstate_max_freq
 /sys/devices/system/cpu/cpufreq/policyN/amd_pstate_prefcore_ranking
 /sys/devices/system/cpu/cpuN/acpi_cppc
 
 $ sudo dmesg -H
 [… ominous silence about amd_pstate …]
 
 $ cpupower frequency-info
 analyzing CPU 1:
   driver: amd-pstate-epp
   CPUs which run at the same hardware frequency: 1
   CPUs which need to have their frequency coordinated by software: 1
   maximum transition latency:  Cannot determine or is not supported.
   hardware limits: 400 MHz - 4.31 GHz
   available cpufreq governors: performance powersave
   current policy: frequency should be within 2.38 GHz and 4.31 GHz.
                   The governor "powersave" may decide which speed to use
                   within this range.
   current CPU frequency: Unable to call hardware
   current CPU frequency: 3.57 GHz (asserted by call to kernel)
   boost state support:
     Supported: yes
     Active: yes
     AMD PSTATE Highest Performance: 255. Maximum Frequency: 4.31 GHz.
     AMD PSTATE Nominal Performance: 219. Nominal Frequency: 3.70 GHz.
     AMD PSTATE Lowest Non-linear Performance: 141. Lowest Non-linear Frequency: 2.38 GHz.
     AMD PSTATE Lowest Performance: 24. Lowest Frequency: 400 MHz.
 
 $ powerprofilesctl
   performance:
     CpuDriver:	amd_pstate
     Degraded:   no
 
 ,* balanced:
     CpuDriver:	amd_pstate
     PlatformDriver:	placeholder
 
   power-saver:
     CpuDriver:	amd_pstate
     PlatformDriver:	placeholder
 #+end_example
 
 And lo, the 🍃↔🚀 slider appears in the Power Management tray widget.
 
 Nervous about entering the "Overclocking" UEFI zone though, and
 concerned about these "Maximum frequencies".
 
 /And does it even help with the game?/
 
 🥁
 
 No.  No it does not; no discernible difference in FPS nor vibes.
 
 Will assume this new baseline cannot hurt - OT1H "overclocking" is
 scary, OTOH Linux now has a finer handle on the CPU and hopefully will
 not overwork it to death?
 
 -----
 
 Chronologically, the events of the following addenda were weaved
 together with those of the next section; figured I would append them
 here to give the reader some closure on this shaggy dog subplot.
 ** Addendum Ⅰ — CPPC Considered Harmful, apparently
 [[https://www.techpowerup.com/forums/threads/what-fixed-stuttering-and-random-framerate-spikes-in-games-for-me.327264/][aska33j proclaims]] that /disabling CPPC/ "fixed stuttering and random
 framerate spikes in games for [them]" so… roundtrip to UEFI, disabling
 that.  The =amd_pstate= warning is back; the "Power Profile" slider is
 no longer accessible in the systray widget; no discernible effect
 in-game anyway.
 ** Addendum Ⅱ — BIOS update
 For the modest price of [[file:maintenance.org::*Our protagonist sets forth][a BIOS update]], the =amd_pstate= driver now
 initializes successfully without me having to mess with
 {{{glitch(Overclocking Settings)}}}.  Welcome back =amd_pstate= 🤝
 * Sᴇᴠᴇʀᴀʟ Wᴇᴇᴋꜱ Lᴀᴛᴇʀ
 - [[https://www.gamingonlinux.com/forum/topic/5475/page=1/][ridge reports]] "bad frame pacing on AMDGPU",
   - when vsync is turned off: a non-factor in my testing,
   - lots of useful information in that thread though and
     interesting-sounding pointers,
   - [[https://www.gamingonlinux.com/forum/topic/5475/page=2/#r42519][Shmerl]] says:
     - games can cause stutter by underloading the GPU, causing it to
       drop out of "high performance mode",
       - (=amdgpu_top= and =radeontop= do confirm that lag spikes
         correlate with GPU usage drop)
     - see [[https://gitlab.freedesktop.org/drm/amd/-/issues/1500][drm/amd#1500]]:
       - /lots/ of sysfs noodling there; unfortunately, none of the
         suggested settings for =power_dpm_force_performance_level= &
         =pp_power_profile_mode= change the symptoms.
   - Since GamingOnLinux seems full of knowledgeable folks, posted [[https://web.archive.org/web/20241220053228/https://www.gamingonlinux.com/forum/topic/6437/][a
     new topic]] there… but then [[https://web.archive.org/web/20250102185206/https://www.gamingonlinux.com/forum/topic/6463/][the UK OSA dropped]].
 
 - In [[https://gitlab.freedesktop.org/drm/amd/-/issues/3618#note_2689087][this drm/amd#3618 thread]], @agd5f suggests "6.11 stable kernels"
   include a fix for the issue at hand there and a further rework "was
   submitted to 6.13"; @mattipulkkinen reports happy results with
   6.13-rc2; symptoms persist here with 6.12.8.
 
 - Piggybacked onto [[https://gitlab.freedesktop.org/mesa/mesa/-/issues/11300][mesa/mesa#11300]]:
   - common: Hades Ⅱ, iGPU, recent kernel & Mesa, Proton Experimental,
   - differences: Fedora, GNOME, X11,
   - noteworthy: good performance on Windows,
   - suggestion by @Venemo: downgrade & bisect Mesa.
     - Tempting, though scared of bricking graphical sessions and/or
       ending up with a frankensystem (intalling binaries under a
       prefix: easy; keeping track of runtime config tweaks and cache
       artifacts: fraught).
     - {{{narrator(Ten false leads later)}}}
     - The factory@ announcements say Mesa was upgraded from 24.2.7 to
       24.3.0 [[https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/6YXCWH4C7Z2PNP5UUWCQPH5KNI2JILYV/][in snapshot 20241124]].  The Mesa docs explain how to test
       uninstalled builds (kudos for the clear
       instructions![fn:mesa-builddeps]) so gave it a shot: a freshly
       built 24.2.7 behaves exactly like the current distro version
       (24.3.4), so no smoking gun there.
 
 [fn:mesa-builddeps] Took a couple of kicks to start the build engine:
 ~zypper source-install --build-deps-only Mesa~ did not cut it.
 Probably should have looked at Tumbleweed's spec file to get a
 matching build configuration; instead ~zypper install~'ed my way to
 victory - needed ~libclc llvm llvm-devel libLLVMSPIRVLib-devel clang
 clang-devel python3-ply rust rust-bindgen rust-cbindgen~.
 
 
 - In [[https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/issues/164][upower/power-profiles-daemon#164]], @Nyan reports problematic iGPU
   capping; not convinced this is applicable though, given the reported
   symptoms (video playback is fine here).
 
 - Seen reports of Variable Refresh Rate causing problems:
   - searched high and low to understand why VRR appears nowhere in
     Plasma settings, despite the start menu turning up "Display
     Configuration" when searching for "VRR",
   - mystery solved by ~kscreen-doctor -o~: =Vrr: incapable= 🤷
 
 - Found that forum post about leaving CPPC disabled to fix
   stuttering—see [[*Addendum Ⅰ — CPPC Considered Harmful, apparently][addendum Ⅰ in the previous section]].
 
   No visible effect for me; left it disabled anyway from there on
   since enabling it never had an effect in the first place, and I am
   keen on experimenting one parameter at a time.
 
 - Looking at Steam forums, [[https://steamcommunity.com/app/1145350/discussions/1/596260472619121965/][some folks]] do report FPS drops /shortly
   after the update/:
   #+begin_quote
   it started fine after the major update, now suddenly im stuck with
   40~50 fps with micro sutters
   — December 6 2024
   #+end_quote
 
 - After AMD drivers & Mesa, figured I could look at vkd3d's issue
   tracker.  [[https://github.com/doitsujin/dxvk/issues/4436][doitsujin/dxvk#4436]] and
   [[https://github.com/ValveSoftware/steam-for-linux/issues/11446][ValveSoftware/steam-for-linux#11446]] looked somewhat promising:
   reports of lag on "KDE Tumbleweed Wayland", not long before my
   symptoms began (November 2024)); alas, ~LD_PRELOAD=~ does not help.
   - {{{narrator(clicks through duplicates\, out of GitHub & into
     [[https://reddit.com/r/linux_gaming/comments/1htcxfj/system_green_screens_regularly_during_more/m5da9ey/][Reddit]])}}}
 
     #+begin_quote
     Alternatively, remove the offending line in
     =/usr/share/drirc.d/00-radv-defaults.conf=
     #+end_quote
 
     {{{narrator(discovers [[https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-radv-defaults.conf][=/usr/share/drirc.d/=]])}}}
 
     Computers were a mistake.
 
 - Peeked at [[https://github.com/HansKristian-Work/vkd3d-proton/blob/master/.github/ISSUE_TEMPLATE/bug_report.md][vkd3d-proton's issue template]] and idly ran with
   ~PROTON_LOG=1~.  Over the course of 30 seconds or so, the log file
   gets flooded with 3MB's worth of =trace:unwind:dump_unwind_info= 🤨
 
 - VRAM usage is always close to full, even when not playing games.
   "At rest", the Plasma shell consumes ≈410MB over 512MB available.
   - [[https://forum.kde.org/viewtopic.php%3Ff=111&t=165779.html][Lissanro reported]] in 2020 that changing Plasma's rendering backend
     to /Software/ freed up some VRAM.
   - Indeed, bringing up the Plasma Renderer menu, switching to
     /Software/, logging out & back in frees up some VRAM.  It also
     yields compositing glitches 🤷
   - More to the point, /it has no effect on the symptoms in-game/.
 
 - Figured I would ask ValveSoftware/Proton about the logs; filed
   [[https://github.com/ValveSoftware/Proton/issues/8424][#8424]]; got dup'd into [[https://github.com/ValveSoftware/Proton/issues/7805][#7805]], per the "one report per game" policy.
   That issue is about a /crash on Alt-Tab/, with an /Nvidia dGPU/;
   unsure how lumping our two reports together will help.  Had to try 🤷
 
 - Found [[https://gitlab.freedesktop.org/drm/amd/-/issues/2516][drm/amd#2516]]; noticed that I have
   - =/sys/module/gpu_sched/parameters/sched_policy=: 1
   - =/sys/module/amdgpu/parameters/sched_policy=: 0
   Changed the kernel command-line to set the former to 0, as suggested
   in that issue; symptoms persist.  No idea what the latter is about,
   nor how it differs from the former.  I can find [[https://docs.kernel.org/gpu/amdgpu/module-parameters.html#sched-policy-int][the docs for amdgpu]]
   but nor for gpu_sched.
 
 - [[https://old.reddit.com/r/archlinux/comments/1gzy0xd/amdgpu_regression_on_kernel_612_choppy/m1dn05z/][Some folks]] report =amdgpu.dcdebugmask=0x10= (≡ =DC_DISABLE_PSR=)
   fixing "choppy performance".  No effect here.  Could try setting
   [[https://www.kernel.org/doc/html/v6.13/gpu/amdgpu/module-parameters.html#dcdebugmask-uint][other values]]…
 
 - I caved—not sure why, I think seeing the amount of unhappy kernel
   noises in journalctl got to me—and grabbed the latest BIOS from
   msi.com, flashed it, which restored =amd_pstate=.  See [[*Addendum Ⅱ — BIOS update][addendum Ⅱ in
   the previous section]].
 
   OT1H now power management interfaces (Plasma's, powerprofilesctl,
   cpupower) seem "fully operational"; OTOH symptoms feel worse: the
   game can no longer sustain 60 FPS even in sub-areas that were
   previously fine.  There is still a visible difference between
   - OK-ish sub-areas - 55 FPS with occasional lag spike,
   - bad sub-areas with out-of-control sawtooth FPS.
 * The Warsong Update
 Whew these new Crossroads do look great, so long as I stand still.
 Artemis is paying a visit?  There's a new garden corner with a Hades
 bust and a narrator prompt?  There's animals /all over the place/, and
 *[[https://store.steampowered.com/news/app/1145350/view/503942841152569404][what's this?]]*
 
 #+begin_quote
 - The moon now shows different phases in the Training Grounds vista scene
 #+end_quote
 
 /Be still my heart./
 
 No changes in framerate patterns though; still getting "sawtooth 55"
 FPS near the most edges, stable "linear 60" at some corners like the
 hot springs, and "sawtooth 40±15" everywhere else.
 
 - Spotted =amdgpu: Runtime PM not available= in dmesg; found no
   actionable advice about this.
 
 - Found a new crop of "choppy performance" issues—[[https://gitlab.freedesktop.org/drm/amd/-/issues/3658][drm/amd#3658]],
   [[https://gitlab.freedesktop.org/drm/amd/-/issues/3742][drm/amd#3742]]—no miracle cure there.
 
 - Driver developer Timur Kristóf offers [[https://old.reddit.com/r/linux_gaming/comments/y7zl45/psa_for_amdgpu_users_kernel_519_and_likely_60_is/isyryb1/][some tips]] to diagnose
   issues with the graphics stack.
 
 - Caved and filed [[https://gitlab.freedesktop.org/drm/amd/-/issues/3993][drm/amd#3993]].
   - Got a very fast shot in the dark: try =amdgpu.dcdebugmask=0x610=.
     Thanks!  No effect unfortunately.
   - Since that was as exhaustive a report as I published this far
     (ignoring… whatever /this/ is), figured I would also send an email
     to Supergiant's support address.
 
 - Tired of annotating "openSUSE Tumbleweed" with "… with Packman
   repository but it is mostly just codecs except well there is Mesa in
   there", so for intellectual honesty, purged
   Packman[fn:purge-packman], restarted, loaded the game.
   - There, same symptoms; Packman exonerated.
 
 [fn:purge-packman] As simple as:
 #+begin_src
 sudo zypper removerepo Packman
 sudo zypper dist-upgrade --allow-vendor-change --remove-orphaned
 #+end_src
 Then confirmed absence of strays with ~zypper packages~ (with
 ~--orphaned~, then with ~| tr -s ' ' | cut -d'|' -f2 | sort | uniq
 -c | sort -hr~ to double-check repositories in-use).
 
 
 - Lobsters featured [[https://store.steampowered.com/news/app/2731870/view/4666382742870026335][this story]] about game developers working around
   "catastrophic performance loss on AMD" with some DX11 memory usage
   patterns, solved by "changing the buffering implementation of GPU
   uploads".  Searched for actionable things to do with that anecdote,
   found none.
 
 - Noodled in UEFI some more.
   - Changed the "graphic adapter" knobs from "PEG" (PCIe Graphics) to
     "IGD" (Integrated); not that this changes much since there is no
     PCIe card anyway.
   - Changed "Integrated Graphics" from "Game Mode" to "Force"; bump
     UMA Frame Buffer Size to 4 GB.
   - Activated A-XMP "Profile 1" (boosts DDR4 clock speed).
 
 - Pondered [[https://docs.mesa3d.org/drivers/radv.html][RADV]] vs [[https://github.com/GPUOpen-Drivers/AMDVLK][AMDVLK]].
   - The latter is not easy to install on openSUSE.
   - Not sure AMDVLK supports my iGPU anyway.
 
 - Sent [[https://community.amd.com/t5/pc-processors/game-stutter-on-opensuse-tumbleweed-with-amd-ryzen-5-pro-4650g/m-p/750105][a message in a bottle]] on the AMD community forums.
 
 - Stumbled on more recent threads:
   - [[https://old.reddit.com/r/AMDHelp/comments/1isclpw/i_am_beyond_frustrated_with_the_stutter_issues_on/][another AMD castaway]] with commenters suggesting to enable
     C-States.
   - [[https://community.frame.work/t/wayland-lag-stuttering-since-kernel-6-11-2/59422/28][framework users]] pointing at three different drm/amd reports 😵‍💫
 ** What if it /was/ the new SSD though
 - [[https://old.reddit.com/r/diablo4/comments/1g7o5kz/kingston_ssd_firmware_update_fixed_stuttering/][LockeDown815]] says bumping their Kingston NVMe SSD firmware fixed
   stuttering in Diablo Ⅳ.
   - [[https://old.reddit.com/r/linux_gaming/comments/aodqqw/psa_dont_buy_ssds_from_the_kingston_a400_line/][jayomegal]] says the A400 SSDs (👋🥺) have "fucked firmware".
   - [[https://old.reddit.com/r/linux_gaming/comments/gt13h5/what_could_i_do_with_my_kingston_a400_ssd_if/][tubi_carrillo]] asks the tough questions - how is a Linux user to
     update their firmware when the vendor does not partake in LVFS and
     only offers a Windows utility?
   - [[https://bbs.archlinux.org/viewtopic.php?id=243614][xhpohanka]] reports "strange system lags" after cloning their system
     on a SA400.
 - Welp, time to [[file:../hirondell/maintenance.org::*2025-03][resurrect hirondell's Windows partition]] 🧟
   - Braved [[https://www.petiterepublique.com/2025/03/08/ce-samedi-8-mars-2025-des-rafales-de-vent-a-plus-de-120-km-en-haute-garonne/][the wind]] & fetched a 2.5″ SSD-to-USB case.
   - WELP, Kingston® SSD Manager fails to identify the disk 🙄
     #+begin_src
     Device scan complete. Updating views...
     \\.\PHYSICALDRIVE0: Detected as the primary drive, KScode2 Identify failed, BusType:11
     \\.\PHYSICALDRIVE1: Not supported - Identify failed, BusType:7
     Updating devices list...
     \\.\PHYSICALDRIVE0: SK hynix SC311 SATA 128GB, SCSI\DISK&VEN_SK&PROD_HYNIX_SC311_SATA\4&AAF871B&0&000000
     \\.\PHYSICALDRIVE1: KINGSTON  SA400S37480G SCSI Disk Device, SCSI\DISK&VEN_KINGSTON&PROD__SA400S37480G\6&1EA4F16A&0&000000
     #+end_src
     Nevermind then!  Moving on.
 ** Time to come clean
 There was one other thing I changed on this reinstallation: I used XFS
 instead of Btrfs for my home partition.  Not sure why; [[https://old.reddit.com/r/openSUSE/comments/3dambq/why_btrfs_for_but_xfs_for_home/][some folks say
 it's a good idea?]]
 
 And /of course/ there is [[https://bugzilla.kernel.org/show_bug.cgi?id=202349][a kernel bug]] showing that somehow "sustained
 write operations with XFS" conflict with "GPU creating memory
 pressure" or something.  /Of course/.
 
 tl;dr
 
 - backed everything up
 - wiped the main disk; re-installed with Btrfs for root & home
   - left XFS on the secondary disk (NVMe, Samsung 980)
   - [[https://forums.opensuse.org/t/boot-broken-after-fresh-install-fstab-tweak/183405][tripped over SELinux 🤦]]
   - no changes in framerate
   - so XFS exonerated?
 - let's exonerate the Kingston SSD while in there 🤷
   - unplugged the SATA SSD
   - wiped the NVMe disk
   - re-installed on the NVMe disk (full Btrfs)
   - no changes in framerate
 ** 😐
 - XFCE
   - by default: much worse
   - with compositing disabled: on par with plasma
 - =PROTON_USE_WINED3D=1=: "Renderer creation failed. Pleaes ensure
   your graphics card meets the minimum rqeuirement."
 - [[https://discord.com/channels/456889434672201729/1229836992829984830/1350397520718598154][discord, I guess]]
 - noticed =d3d12_device_init_workarounds: AMDGPU broken kernel detected=
   - =VKD3D_CONFIG=skip_driver_workarounds=: no changes
   - vkd3d-proton issue
 - proton-ge?
   - installation docs point to [[https://github.com/lutris/docs/blob/master/InstallingDrivers.md#amd-1][Lutris driver installation instructions]]
     - most packages were indeed installed automatically by the distro
     - except =libdrm_radeon1-32bit=: installed; no changes
   - installed proton-ge: no changes
 - 6.11.7 → 6.11.8 update had [[https://build.opensuse.org/request/show/1224199][a lot going on]]
 * The unsatisfying ending?
 On March 16 2025, installed Debian (then Bookworm) on the NVMe disk
 (KDE Plasma, Wayland, kernel 6.1).
 
 Installed Steam; installed Hades Ⅱ; game ran great; played like no
 tomorrow.  Hissed at Trixie, stubbornly kept playing on Bookworm.  All
 the while, kept daily-driving the Tumbleweed installation on the SATA
 disk; just rebooting into my "BookwormCube" for Hades Ⅱ sessions.
 
 In September–October, caught & handled =SIGSKONG= on Tumbleweed; from
 October 25 through November, rebooted into the BookwormCube® to play
 Hades Ⅱ's endgame & chase cheevos.
 
 Bottomline: ending meh, comparatively with Hades Ⅰ?  Game still rules.
 
 Tech-wise, for all my efforts debugging this stutter, I learned
 nothing, beside a truckload of ineffective system knobs.  Last checked
 Tumbleweed's performance [[https://gitlab.freedesktop.org/mesa/mesa/-/issues/11300#note_3003120][in August]] (kernel 6.15.6;
 kernel-firmware-amdgpu 20250708; Mesa 25.1.5 & 25.3.0-devel with
 =nogttspill=); no improvements.
 
 /Fin/ 🎬
 * Dramatis parametra
 There is not a single parameter I can rule out, months into this
 farce.  Condensed summary of the whole affair:
 
 - In-game settings
   - *Fullscreen* /windowed
   - V-Sync *on* /off
   - Graphics *low* /mid/high
   - Resolution *1920×1080* (native) /lower
 - Steam
   - Launch options
     - ~LD_PRELOAD=''~
   - Proton
     - versions: *hotfix* (Steam default) /older/GE
     - vkd3d-proton
       - ~VKD3D_CONFIG=skip_driver_workarounds~
 - Desktop environment: *Plasma* /Xfce
   - *Wayland* /X11
   - Rendering Backend: *Automatic* /Software
   - Variable Refresh Rate: "incapable"
 - Filesystem: *Btrfs* /XFS
 - Kernel & drivers
   - *RADV* (/AMDVLK)
   - Mesa
     - version
     - =RADV_PERFTEST=
   - amdgpu
     - sysfs
     - dcdebugmask
   - amd_pstate
 - Firmware
   - motherboard
   - SATA SSD
 - UEFI
   - UMA Frame Buffer Size (≡ VRAM?)
   - A-XMP Profile
 - Hardware
   - Iiyama PL2710HD
   - [[https://www.lindy.eu/2-Port-DisplayPort-1-2-USB-Type-C-USB-2-0-Audio-Cable-KVM-Switch.htm?websale8=ld0101.ld021102&pi=42346&ci=30][Lindy No. 42346]] KVM
 
 Caption:
 - "*A* / B": *A* is nominal choice
 - "A (/B)": have not actually tried B