Modern AMD-s Linux rendszereket negatívan érintő, 20 éves chipset workaround javítását hozhatja a Linux 6.0

Kernel

Az AMD egyik mérnöke a közelmúltban rámutatott, hogy egy, a Linux kernelben jelen levő, ~ 20 éves chipset workaround bizonyos esetekben a modern AMD-s Linux rendszereket negatívan érintheti teljesítmény szempontból. Szerencsére, a javítás már úton van és megérkezhet a 6.0-s Linux kernellel.

( xc0m v | 2022. 09. 27., k – 12:02 )

Szerintetek ezt vissza fogják rakni régebbi Arch kernelekbe is?

( uid_16313 | 2022. 09. 27., k – 16:01 )

Sponsored by Intel? (Mármint 20 évig)

( locsemege v | 2022. 09. 27., k – 16:32 )

Nem tudom, hogy érintett-e az AMD Ryzen 7 5700G, de mindenképp örülök a javításnak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A cikk szerint csak Zen3 érintett, de az 5700G az pont az az architektúra. Az én 6800H-m is érintett. Amit én nem értek, hogy kb. ugyanaz a kód hajtja az összes Zen-t (Zen, Zen+, Zen2, Zen3, Zen4), akkor miért csak a 3-as generáció érintett?

Egyébként nem csak a Linuxnál élnek túl ilyen régi hardverekre bevetett hackek, hanem a legutóbbi BSDCan konferencián is az ürge, aki a FreeBSD bootolásának a gyorsításán dolgozott, mondta, hogy volt egypár ilyen a kódban, hogy 20 éves hardverekhez bevetett acpi és egyéb hackek miatt várakozott a kernel bootkor, nem nagy időtartam volt egyiknél sem, egy kis 20 ms itt, egy kis 30 ms amott, de némelyik elszaladt ilyen 200-300 ms környékére is, ráadásul néhány esetben CPU magonként jelentkezve, stb., de ezek a végösszesítésben tetemes időre ki tudnak jönni a teljes bootidőhöz mérten. Ráadásul a sok millió kódsor között eléggé megbújnak ezek, nehéz őket kiszúrni, tetten érni.

Én is nagyon becsülöm ezeket a projekteket, hogy ilyen teljesítménynövelő javításokon dolgoznak, és nem az a bs megy, mint a MS-nál, hogy annyiból áll a fejlesztés, hogy mesterségen avultatnak el gépeket, meg szebbek-színesebbek az ikonok és középre vannak kényszerigazítva a tálcán (ala WIn11). Ráadásul nem ez az első, pár hete valami Intel GPU-kat meg AMD RADV drivert érintő optimalzáció is volt, előtte meg rémlik, hogy a /dev/rand és /dev/urand kódon is több száz százalékot gyorsítottak, és a headerfájlok rendberakásánál is jelentősen gyorsult a Linux kernel fordítási ideje, stb.. Még a CPU sebezhetőségek elleni foltokon is annyit optimalizáltak már, hogy sokszor lassabban fut a rendszer, ha a mitigations=off paraméterrel van indítva a kernel, mivel ugyan a folt olyankor nem lassít, de a rá épülő optimaliziációk is ki vannak lőve. Sőt, a Facebook (vagy talán a Google) meg a linuxos boot gyorsításán dolgozik, valami morbid 1 másodperc alá bevitték, igaz nem fullos desktop kernel, hanem valami spéci embedded/szervers cucc, spéci systemd-hackekkel, de az se hangzik rosszul, igaz az még nincs beleportolva sehova.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A cikk szerint csak Zen3 érintett

Nem, nem ez van a cikkben. Az AMD-s mérnök éppen Zen3-mon csinált mérést, de sehol nem azt írták le, hogy csak a Zen3 érintett. Minden modern Zen-architektúra érintett, pontos listát nem adtak. Csak éppen az AMD-s mérnök Zen3-mon csinált mérést erről, és ez alapján csinálták a fixet.

Akkor jó. Én is ezt gyanítottam, de ilyen „újságírás”-nál eléggé úgy fogalmaznak, hogy értsd, ahogy akarod. Midenképp úgy lenne logikus, hogy az összes Zen érintett, sőt, ahogy olvasom, az Inteli is a 8. gen alatt.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( ricsip v | 2022. 09. 27., k – 16:49 )

Mondjuk azért elég cizellált esetkezelés az a "ha-nem-intel" --> akkor lassítunk megoldás.

Nope, az már a "fix". Ha nem intel, akkor nem csinál semmit.

A leírás szerint a korszerűbb (értsd első core i7-től kezdve, kb 13 éve) intelek már eleve bele sem futottak ebbe a függvénybe.

A szar ügy ebben, hogy igazából nem tudni, hogy eredetileg melyik konkrét hardver miatt került be ez a workaround. A szerző is csak tippelgeti hogy Intel oldali lehetett a bug, de nem teljesen értem hogy jutott erre a következtetésre ("this also assumes the motivating chipset issue was Intel-only"). Szerintem inkább csak vakon feltételezi és lehet, hogy közben valami régebbi nem-Intel vason regressziót csinál.

Régóta vágyok én, az androidok mezonkincsére már!

Akkoriban még nem volt git, hogy a blame-et megnézzék :D 

Amúgy hihetetlen mekkora baromságok vannak. Pl AMI bios legújabb szériája, ami amd 6000 és intel 12gen szériájú gépeknél több gyártónál is elcseszi a beépített billentyűzet kezelést. Az is valami irq1 gányolás workaround, amire már nincs szükség, de még aktív. És most egyenként veszegetik fel a dmi neveket, hogy mikre ne csinálja. Persze lehet eddig volt rossz és arra volt a workaround... de most meg így rossz.
https://lore.kernel.org/linux-acpi/CAJZ5v0g=x2cBoFjOufOD6_4nLHhRqoFmM+4…

Amd 6k-ra pl külön bekerült már kivétel https://github.com/torvalds/linux/blob/master/drivers/acpi/resource.c

* IRQ override isn't needed on modern AMD Zen systems and
* this override breaks active low IRQs on AMD Ryzen 6000 and
* newer systems. Skip it.

Régi dolgok karbantartása, régiből új kódok esetén a már nem szükséges dolgok kigyomlálása nem mindig egyszerű. Saját kódomon is tudom. Amikor ugyanarra a problémára új mikroszámítógépet terveztem, s a kódot az új hardware környezetre portoltam, lett olyan bug, ami abból eredt, hogy csak az adott portbitre hivatkozás lett átírva egy #define-ban, viszont az új hardware-ben a működés is megváltozott, de ezt a tartalmi változást már nem implementáltam. Hát... úgy is működött, mint a megzavarodott vassorrú bába a mágneses viharban. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( gazsiazasz | 2022. 09. 27., k – 18:38 )

sittes linux kernel, part 5242344

+1

Nem is értem az ilyen hozzászólásokat. Szerintem az uint8_t i; for (i = 0; i < 10; i++) printf("%s%u", i ? " " : "", i); printf("\n"); szintű programnál sohasem írt összetettebbet. Megnézném, mekkora kódot, milyen bonyolultságú feladatot mennyire áttekinthetően és hibátlanul old meg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért ez architekturális probléma is. Jó lenne, ha a hardverspecifikus workaroundok hardverspecifikusan lennének implementálva, ideális esetben alaposan dokumentálva, hogy melyik hardvert és miért érinti, nem pedig a kódbázist teleszórva random elágazásokkal, ami aztán vagy ráfut más hardverek esetén is, vagy nem.

- Egyreszt nekem ugy tunik, hogy ez regebbi problema lehet, amikor meg nem voltak meg a kesz "library" megoldasok a hardverspecifikus workaroundokra. Nyilvan ido kozben tanultak a fejlesztok is a tapasztalatokbol. Termeszetesen abban igazad van, hogy idovel nem artana refaktorolni ezeket a regrol marad megoldasokat.

- Masreszt kicsit talan meg kell vedenem ezt a workaroundot. Ha (1) nem tudni, hogy csak egy konkret hardvert erinti-e, es (2) a felesleges workaround funkcionalis bajt nem okoz, (3) de erintett hardveren a hianya igen. Valamint (4) a workaround csak lassulassal jar. Akkor szerintem igenis az a "safe" megoldas, hogy a bekapcsolt workaround a default viselkedes, es legfeljebb egyesevel kivesznek hardvereket belole, amirol ismert, hogy nem kell a workaround.

Régóta vágyok én, az androidok mezonkincsére már!

( turul16 v | 2022. 09. 28., sze – 10:41 )

Hangaztos cikk, lenyegen egy i/o utasitasnyival lassaban megy aludni egy core,
IMHO ezert nem kell varni az uj kernelt.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ezért lenne jó ha valaki (értelmesebb, és hiteles) kóder ranézne a before-after-re, és leírná blikk-mentesen TLDR módon mi volt itt a tényállás. Mert elég szenzációhajhász ez a felhajtás körülötte. A valóságban meg esélyes hogy szart se számított. Különben már 10 éve is szúrta volna valakinek a szemét. Vagy lehet hogy threadripperen 64 core 128 thread-en már kimutatható a hátrány, és ebből kerítettek egy szenzációhajhász bullshit cikket a firkászok. Ugye nem szólt nagyot a ryzen 7000 bemutató, ezért most kell a hírverés az amd-nek a techmédiában mindenhol.

A lényeg ebben a bekezdésben van:

However, sampling certain workloads with IBS on AMD Zen3 system shows that a significant amount of time is spent in the dummy op, which incorrectly gets accounted as C-State residency. A large C-State residency value can prime the cpuidle governor to recommend a deeper C-State during the subsequent idle instances, starting a vicious cycle, leading to performance degradation on workloads that rapidly switch between busy and idle phases.

Ha jól értem ez azt jelenti, hogy ez elrontja a cpuidle governor statisztikáját, ezért a CPU-t alacsonyabb teljesítményre állítja, mint amit a workload indokol.

Valoban aggressivabbnak tunt a power save amd-n default-bol mint intelen.
ACPI -nak vannak olyan regiszteri ami olvasasa -ra csinalnak valamit (modern design keruli a side effect read eseten illetve i/o portok hasznalatat).
Egyenlore nem taltaltam ra dokumantacioban hogy az xpm_timer_block olvasasa -nak lenne mellekhatasa.
Lehet hogy egy AMD workaround ez a register olvasas kihagyas ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.