Linus "csúnya" regresszióba futott a Linux 6.8 korai kódja tesztelésénél

Kernel

A 6.8-as Linux kernel beolvasztási ablaka nyitva, Linus a merge-elés és tesztelés közben egy "borzasztó" regressziót tapasztalt: az empty kernelfordítása 22 másodpercről 44 másodpercre nőtt!

Just a note that I'm currently bisecting into this merge for a horrendous performance regression.

It makes my empty kernel build go from 22 seconds to 44 seconds, and makes a full kernel build enormously slower too.

I haven't finished the bisection, but it's now inside *just* this pull, so I can already tell that I'm going to revert something in here, because this has been making my merge window miserable.

You've been warned,

Linus

Részletek itt.

( timi | 2024. 01. 11., cs – 13:45 )

Ő sem intelt használ hanem AMD procit. 

Nem értem ez miért releváns. Egyébként meg azért használ AMD-t, mert az ő felhasználására az a legjobb. Ilyen sok magon futó nagy kódforgatásos mókákra, mint a kernelfeljesztés, arra a Threadripper a legjobb, az Intel ezen a fronton nincs a nyomában. Desktop és mobil prociknál szoros a verseny az Intel és AMD között, de a workstation és szerver szegmensében az AMD abszolút viszi a prímet még mindig (magok és szálak száma, cache mérete, ár/teljesítmény aránya).

Egyébként meg Linus mindig is inteles volt, minden gépe az volt, írta, mikor a legújabb gépét vette, hogy ez az első AMD-s rendszere. Azóta kapott mellé egy másik threadripperes gépet is emlékeim szerint, level1tech építette neki szponzorok segítségével, azzal együtt már nem az első, gyaníthatóan nem is lesz az utolsó. Kernelfejlesztőknél ez szokásos, Kroah-Hartman is Threadripperen tolja, meg van fent a YT-n jó pár kernelfejlesztős interjú, sok évről ezelőttről, akkor is többen tolták sok magos régi Opteronon, mert akkoriban az adott olcsón sok magot.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Bocs, hogy közlöm a valóságot: az Intel továbbra is piacvezető, vagyis, hacsak nem én diszponálok a világ összes beszerzése felett, akkor ne nevettesd ki azzal magad, hogy nekem címzed kizárólag a fájásod. Nagyon sok helyen előbbre való a stabilitás a kísérletező kedvvel szemben. Az, hogy te az IBM kutató kísérletező laborjában találtad meg a számításod, ne legyen már irányadó mindenkinek :D

További jó kísérletezést! Esetleg, javaslok mellé egy EV beszerzést :D

trey @ gépház

Gaming-ben még mindig erősebb kicsit az Intel, de nagyon egálban vannak.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

valoszinuleg nem ilyenekre gondolt, hanem asztali gepre dedikalt kartyaval.

egyebkent az msi kezikonzola meteor laket hasznal, sokat gyorsult az elozo generacio ota

https://www.phoronix.com/review/meteor-lake-arc-graphics

https://www.phoronix.com/news/MSI-Claw-A1M

https://www.phoronix.com/review/z1-extreme-meteorlake

neked aztan fura humorod van...

Ezekben az energiatakarékosság miatt vannak ezek a procik. Itt most az erőről volt szó, az elérhető nyers fps-maximumról. Ezzel egy szóval nem mondtam, hogy az AMD gyenge, mert ahol el is van maradva, csak nagyon kevés % a különbség, de azt jóval kisebb fogyasztás és melegedés mellett hozza.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Raynes v | 2024. 01. 11., cs – 13:56 )

Szerkesztve: 2024. 01. 11., cs – 14:01

Az nem biztos, hogy ez az 50%-os beesés minden kernelfordításra skálázódik, pl. egy lassabb gépen, egy 20+ perces kernelbuild nem biztosan lesz kétszer olyan hosszú. Nem aggódok, meg fogják találni az okát.

Időközben nekem a 6.7 még csak most ért le. Baj nem lenne vele, de ahogy látom, az Arch-rendszerem memóriaigénye nőtt sajnos megint, 385MB-ról (konzekvens saját mérési módszer szerint) 445-re nőtt a memóriafogyasztás, igaz ez lehet az 1.0-ás Pipewire, új systemd, vagy az új dbus-broker, stb. miatt is. Jó pár hete nem néztem, lehet a növekedés már a 6.6.x-nél beállt, de mindenesetre most tudatosult (ezt a hibát nem követem el újra, mostantól logolni fogom a memóriafogyasztást boot után, külön a kernelre is).

Nem jó ez így, hogy néhány hét alatt bloatosodik a rendszer 60 megát, főleg ilyen minimalista rendszernél fájó (csak alap rendszer, X.org, 2 MB-ot foglaló minimális tiling WM + sxhkd/polybar, semmi extra szolgáltatás szinte a dbus, ntp, dhcpcd, wpa_supplicanton kívül), tehát semmi login manager, automount, stb. megoldás nem fut. Ez még néhány éve 200 megából megállt, mostanra duplázódott. Sőt, régen 440 mega körül egy komplett Gnome3.x vagy KDE5 rendszer megállt, pedig már akkor ezek bloatok voltak. Aggasztó ez a Linux jövője miatt.

Természetesen ez modern, mainstream disztrókon még sokkal rosszabb (Ubuntu, RHEL alapúaknál), mert ott nagy DE, sok szolgáltatás, rengeteg Flatpak/Snap, OOM killer, és egyéb szutyok is futkorásznak tömegesen a háttérben, ezek a disztrók már simán vannak már 1 giga felett, a rosszabbak már másfél giga felett aposnak, közelebb a 2-höz, ez már a Win10 fogyasztásával versenyez. Ilyen ütemben lassan a Win11 3-4 gigás idle fogyasztása is meglesz. Azt kell mondjam, hogy van, amiben hajbazernek igaza van a babzsákfejlesztőkkel, meg profitmultikkal kapcsolatban.

Úgy érzem, hogy ez az ára a Linux népszerűsödésének. Úgy, ahogy a laikus tömegeknek közeledik a Linux éve, úgy lesz a Linux egyre bloatabb, egyre Windows/MacOS jellegűbb. Nagy fejlődés volt driverekben, modern UI-knál (VRR, Wayland, HDR, skálázódés, stb.), Proton/DXVK, stb. ügyileg, de ez nem ingyen jön.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

"Nem aggódok, meg fogják találni az okát."

A cikk írásának pillanatában már meg is volt az oka:

https://lore.kernel.org/lkml/CAHk-=wjK28MUqBZzBSMEM8vdJhDOuXGSWPmmp04GEt9CXtW6Pw@mail.gmail.com/

"...it should come as no surprise that the result is

   9c0b4bb7f6303c9c4e2e34984c46f5a86478f84d is the first bad commit
sched/cpufreq: Rework schedutil governor performance estimation"

Szokásos módon, cpufreq es schedutil rontás akarommondani refaktorolás volt a dolog mögött.

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

Na, ez viszont szokásosan erőssége a kerneleseknek meg a nagyobb FOSS projekteknek, nagyon gyorsan találnak meg és foltoznak hibákat, 24 óra sem telik el egy bug észlelésétől, már kint is van a javított változat, amit rolling disztrók általában még kb. aznap terítenek is. Nincs ez a MS-féle patch keddre várás meg egyéb big corporate időhúzás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Na pont ez az. Elhiszem, hogy az NT kernel és az NTFS nincs jól optimalizálva a Linux kernelhez képest, de ha utol akarják érni/túlszárnyalni a Windows-t és a MacOS-t csicsában és desktop képességekben, akkor hozzá érik a hely és memóriaigény is sajnos. Még most is elfér pl az OpenWRT meg a RouterOS is elég kicsi helyen még egy 30 évvel ezelőtti HDD-hez képest is és annyira a belépő routereken sem szállt el a memória mérete, de ha már jön egy komplett asztali környezet, na az tud zabálni.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Közben írtam egy scriptet, ami naplózza a memóriafogyasztást, date, uptime -p, saját szabad memóriát számoló script, free -mw, vmstat -s, ps aux rendezve RSS méretre, pacman -Q segítségével csomaglista verziószámokkal, ezt beletolja egy dedikált mappába, dátumozott fájlnéven, tömörít is xz -9e segítségével. Jó sok adat, de hosszú távon legalább ki fog belőle derülni, hogy mitől növekedik így a memóriaigény.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A sar-ról már olvastam, de sose használtam. Az atop-ról még csak nem is hallottam. Ki fogom őket próbálni, de kötve hiszem, hogy többet mutatnának, mint egy htop, ps, top, vmstat, /proc/meminfo, stb..

Itt az a baj, hogy látom én mi foglalja a memóriát, de nem látom, hogy mi nőtt, mert nem emlékszek, hogy egyes folyamatok régen mennyit fogyasztottak. Azért kezdem naplózni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Meg annyit hogy siman lehet grafikonokat gyartani mondjuk ksar-ral de akarmivel is (gnuplot). Akar egy sima excelbe bedobhato. Es lesznek azonnal historikus grafikonjaid is. Raadasul ugye mondhatod, hogy a grafikonon legyen rajta egyszerre a cou az io meg a memoria hasznalat is. Ugyanugy ahogy kirakja neked ezt a console-ra is ha kered. SAR RULEZ!!! :D

Milyen kibaszott oreg vagyok mar, hogy ilyeneket is tudok :D

"kötve hiszem, hogy többet mutatnának, mint egy htop, ps, top, vmstat, /proc/meminfo, stb.." - hat tenyleg nem ismered akkor a sar-t. Ugyanazokat a hivasokat hasznlja, mint pl a vmstat meg a tobbi, csak nem kulon progikat kell inditanod hanem egyben van az egesz. Egyetlen tool a tobbi helyett. Amugy egy man sar olvasas elegge hatasos az ismerkedesre :D

Amugy a jo kis monitoring rendszereket baszhatja az ember amikor tulterhelt a gep es se a pull, se a push nem megy hogy rogzitsd a metrikakat, de a sar, sadc meg akkor is mukszik egy ideig ha 1000es a load es minden proci csutkaig ki van tekerve az IO meg 99% (kell azert neki az az 1% az IO-bol :D)

Na, közben a memórianaplózós szkriptem megadta a választ majdnem két hónap után, a sors iróniája, hogy egy ideje 385 MB alá esett vissza a rendszer fogyasztása, 340-350 MB környékére. A lényeg, hogy a X.org fogyasztott többet RSS 22 megával, a polybar 11 megával. Mintha valami közös X-es függőség hízott volna, majd visszakarcsúsodott. Az biztos, hogy nem xlib, mert az st terminál fogyasztása nem növekedett, nem csökkent. Talán xcb, mert a bspwm is ingadozott egy kicsit. Fene se érti, hogy Arch-ék mit forgattak bele, majd szedtek újra ki, hogy így változik ide-oda. Sokkal közelebb nem lettem, csak annyival, hogy nem a dbus broker volt a ludas, amire eleinte gyanakodtam.

Az biztos, hogy nem én állítgattam, a konfgfájlok, csomagok nem változtak. A libeknek a memóriafoglalását lehetne valahogy mérni?

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

man pmap

De egyszeru nem lesz, mert az osszes process-bol osszeszeded a libek fogyasztasat, majd aggregalod oket libek szerint, de nem biztos hogy ez jo megoldas a shared libek eseteben ugye, illetve en nem tudom, hogy hogyan tudnad megmondani, hogy az adott virtualis memory page ugyanaz e mint egy masik porcess eseteben egy masik page ugyannak a libnek

Kösz a tippet, ez nagyon jó. Nem is hallottam még erről, de a -x paranccsal szépen mutatja a lib-ek által használt RSS-t. Beépítem a memóriamonitorozó szkriptemben.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( FeriX v | 2024. 01. 12., p – 10:06 )

Szerencsétlen, még egy kávét se tud főzni két fordítás között.

( asm v | 2024. 01. 12., p – 10:54 )

Erdekes ez abbol a szempontbol, hogy a jelek szerint Linus tenylegesen rabootol a frissen buildelt kernelekre a workstationjen.

rajtuk ment keresztul az erintett commit:

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>

ezek szerint vagy egyik se probalta ki, vagy sehol nem jott elo a bug. ha elobbi akkor rossz a workflow :(

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Időközben kiderült (https://www.phoronix.com/news/Torvalds-Perf-Regression-Fix), hogy Threadripper-specifikus a hiba. Na, ezért nem látta senki más. Ryzen-eken reprodukálható, ha az ACPI CPPC név alatt futó BIOS opciót kikapcsolják. Threadripper alaplapokon ez állítólag nem támogatott.

A fix viszont... jesszus. Már a magyarázat is bűzlik a hackszagtól, mint egy balatoni halárus bódéja...

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

igen, mert az intel bugmentes! arrol meg hogy a sok faszlama nem tesztel rendesen, nem en tehetek.

de hogy arnyaljuk is:

Most AMD Zen 2 and newer systems support ACPI CPPC and thus with modern kernels on the Ryzen side typically use the new AMD P-State driver

ennyi a megoldas, halad a technika, es a kor.

Bugmentes a fenét. Ma már minden gyártó drivere, meg a többi cég szoftvere is mind bugos. Sietnek, kapkodnak az „agilisch” fejlesztéssel, morbid közeli határidőkre tolják ki a  gigantikus kódokat, nem tesztelnek rendesen, max. csak valami alap, automatizált AI tesztet eresztenek rá gyorsban, azt ráhagyják a felhasználóra, hogy szívjon vele az. Tipikus mai soydev hozzáállás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ugye a baj az, hogy a Zen2 generációban hiába van támogatva a CPPC, ha - amennyiben hinni lehet a leírásoknak - egyetlen kereskedelmi forgalomba került Threadripper alaplapon sem került bele a BIOS-ba. Állítólag az AMD belső referencia alaplapján támogatott volt, máshol nem. Innentől kezdve sütheted a P-state driveredet, hiába támogatja az adott processzor.

Én nem mondom, hogy ez az AMD hibája lenne, és azt sem, hogy bezzegazintel. Teljesen értelmetlen erre építeni a flame-et. Mondhatni "szerencse", hogy így alakult, különben nem derült volna fény a schedutil governor átírás hibájára.

Ha valamin flame-elni kellene, akkor sokkal inkább az lenne, hogy miféle fix az, hogy hazudjuk be a jelenlegi CPU órajelet +25%-al megemelve, mert akkor "adja ki jól" a Rube-Goldberg algoritmusban a következő időszelet a CPU órajele.

Edit: Ha valakinek kedve van olvasgatni https://www.kernel.org/doc/html/latest/scheduler/schedutil.html Annyit megértettem, hogy az f_max*1.25 már egy mikrooptimalizálás eredménye lehet. Valójában az u*1.25*f_max-ot számolja ki, de u mindig változik, f_max egy adott cpu-n konstans, így inkább ezt szorozza, mint u-t. Sajnos arra több nekifutásra sem sikerült megtalálnom a szövegben bármi magyarázatot, hogy egyáltalán miért van az 1.25-ös szorzótényező az f_des képletben.

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

Na most kíváncsi vagyok jól fejtettem-e meg lejjebb :)

Lényegében igen, de meglep, hogy ők ezzel a 0.8-as "tipping point"-tal magyarázzák, nem pedig exponenciális függvénnyel.

Lehet, hogy azért nem merik nevén nevezni, mert az átlagoló csúszóablak (ami maga is exponenciális súlyozású, csak negatív kitevővel) "elrontja", és innentől az eredő már nem lesz szabályos exponenciális?

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

Na közben fölfogtam. Nem is akkora hack, mint elsőre látszik, csak nincs elmagyarázva.

Ez az az eset, amikor olyasvalaki írja a doksit aki annyira benne van, hogy eszébe sem jut, hogy pont a fő lényeget felejti el leírni.

Értem én, hogy gőzgép schedutil, de mi hajcsa?

Hát az 1,25 hajtja. Ez kb a legfontosabb szám az egész algoritmus működésében.

Az u paraméter már "frekvencia-invariáns" CPU terhelést tartalmaz. Ebben a korábbi CPU kihasználtság * a korábbi CPU frekvenica / max CPU frekvencia van benne. (Ennél bonyolultabb, csúszóablakos átlagolás és tucatnyi korrekciós tényező is benne van, de a lényegen nem változtat.)

Ha a CPU kezdetben minimális órejelen megy és egy processz 100%-ra kitekeri, akkor u=1*f_min/f_max (egyéb korrekciós tényezőket elhanyagolva). Ha az új órajel f_des=u*f_max lenne (ahogy a bugos esetben volt) akkor f_des=f_min lesz, vagyis a CPU sosem mozdul el a minimális órajelről. Legfeljebb, valami speciális esetben tudna esetleg feljebb lépni, ha más korrekciós tényező emelne u értékén.

A 1,25 lényegében az a paraméter ami megmondja, hogy az előző órajelen mennyit kell emelni a következő ütemezési ciklusra. Ez exponenciális felfutást eredményez. Hiányoltam, hogy a doksiban miért nem írják meg, miért pont annyi - valószínűleg nem igazán lényeges a pontos értéke csak 1-nél nagyobb legyen.

Az 1,25-tel lényegében addig emelgeti az órajelet (mindig 25%-al), amíg a CPU kihasználtság 80% alá nem esik, vagy f_max-ot el nem éri.

Érekes, hogy pont ez maradt ki a doksiból és a kód átírásakor a fejlesztő is pont ezt felejetette ki...

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

Arra kell építeni a flame-et, hogy az Intel alaplapok mindig sokkal jobban összecsiszoltak voltak az Intel processzorokkal, mint az AMD meg a kiafasztudjakigyártotta alaplapok. És mivel rendszereket veszünk és üzemeltetünk, nem  egymással nem, vagy szarul működő komponenseket 🤷‍♂️

trey @ gépház

tudnak azért hekkelni... az új gépemnél, amikor vettem, nem működött a bill és a touchpad. Az oka az volt, hogy korábbi biosokban volt egy "bug", amire volt egy workaround beégetve. Úgy tűnik a legújabb ami bios generáció már nem tartalmazza a bugot. Így a workaround pont elrontotta. És fixen beégetett listában volt, hogy pontosan melyik gép milyen modeljénél nem kell alkalmazni a workaroundot - még kernel paraméterbe sem volt kivezetve flag, hogy esély legyen úgy állítani. :D

( bzt | 2024. 01. 14., v – 16:03 )

Nem kell aggódni, lesz abból a 22 másodpercből pikk-pakk 22 perc is, ha tényleg elkezdik telefosni Rust kóddal a kernel forrását!

( marcabru | 2024. 01. 16., k – 11:19 )

Szerkesztve: 2024. 01. 16., k – 11:20

Jezusmaria, hosszabb a build, mi lesz itt, mind meghalunk. 

Ehhez kepest tegnap nalunk valaki benyomott a prodba egy kalap-kabat deploymentet delutan 5-kor, es hazament, en meg szoptam estig az elbaszott alkalmazas feltamasztasaval.