Linux kernel fordítása közbeni RAM-használat csökkentést célzó új patchek

Címkék

Főleg korlátozott fizikai RAM mennyiséggel rendelkező rendszereken lehet majd hasznos:

Updated patches were sent out today that aim to reduce the maximum memory usage while compiling the Linux kernel. In turn for memory constrained systems that attempt to compile the kernel this should lead to less swapping and faster build times [...] Long story short, this patch series undergoing review should help in reducing peak memory use while compiling the Linux kernel and in turn help out with builds particularly for systems with limited amounts of RAM that may otherwise hit swapping during the build process that in turn will cause the build speed to suffer.

Részletek itt.

Hozzászólások

Tegye fel a kezét aki fordít kernelt!

Acer netbook 4 GB memóriával (és AMD C60-as processzorral  - kb 1. gen Atom)  - azért tartom, mert remekül megy rajta a FreeBSD a bhyve hipervisor-ral, rendszeresen 3 (extrém esetben 5) VM-mel.  Miért kéne egy ilyet elengedni? Persze tény, én se fordítok kernelt, de másra még használható. Persze ha kidobnád a Carbon X1-et, szólj - lehet lecserélném et a tökmagot! :-)

Szerintem is. Senki ne akarjon 1-2 giga RAM-os gépen kernelt forgatni. A 4 giga is nagyon a határon van akármihez ma már. A legtöbb gépben van 8-16 giga RAM (nem is drága, 20-65 USD körül mozog, attól függően, hogy 8 vagy 16, DDR2-DDR5-ről van szó, plusz-mínusz némi apró, ha más valutában kell venni). Annyi elég a kernelfordításhoz, tapasztalatból tudom. Persze konkrétan nem baj, ha azért próbálnak a fordítás hardverigényén csökkenteni, de én sem látok ilyen pár százalékos csökkentést hú de nagy szenzációnak. Amelyik gépen nincs elég RAM, az feltehetően elég régiség is lesz, és nem valami jó ilyesmi kaliberű fordítgatásokra. Pl. van nekem egy i5-2520M-es régi TP-em, dual channel 16 giga DDR3 RAM, SATA3 SSD, eléggé vergődik a kernelfordítással, 15-20 perc egy fullosabb kernel, hiába van elég RAM, a proci nagyon soványka már a kettő magjával, nyög a sok millió kódsor terhe alatt (hasonlóan teljesített egy i5-3340M-es és egy i7-2620M-es hasonló gép is). Persze, a kernelt lefordítja, ha valaki nagyon megszorul, nem lehetetlenség rajta megcsinálni, de nem való már ilyenre.

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.”

Már miért ne akarna? Attól, mert vannak nagyobb memóriával szerelt ARM-gépek, sőt cross-compiling, attól még pl. RPi3-ig 1 GB a maximum. Én már 20 éve is elmondtam előadáson, hogy az eredeti UNIX fejlesztéséhez használt, kidobásra itélt gépben 16 kB központi memória volt. Ha a te hozzáállásoddal álltak volna hozzá, ma rohadtul nem így nézne ki a kibernetika.

Mert nem egy jó élmény. Azért ne akarja. Persze, megy rajta, de lassú. Kb. mint mikor emberek 10 fps-sel játszanak, meg 640×480-ban, ultra low-n, textúrák nélkül. Menni megy, csak kérdés mi értelme van, mert élvezet, köszönet nem lesz benne.

A Unix fejlesztése 53 évvel ezelőtt volt, azért beláthatod, hogy azóta volt fejlődés. Meg akkor a kernelek se voltak akkorák, meg a verziók, biztonsági foltok se pörögtek olyan ütemben, hogy állandóan fordítgatni kelljen. Most nehogy már komolyan akarjon valaki bármit tervezni egy olyan gépen, ami pár tizen dollárnak megfelelő befektetéssel nem szerelhető fel elég memóriával. Mert ott gyakran nem csak a memória lesz a szűk keresztmetszet. Fordítani lehet bármin egyébként, egy 486-oson is, kérdés, hogy megér-e valakinek napokat-heteket, hogy leforduljon a kód. RPi sem fordításra való, hanem vezérléshez, meg pehelysúlyú mikroszervernek. Elvileg a Pi4B 8 gigáson elég erőforrás lehet hozzá, bár a proci azon is nagyon sovány lesz, szerintem kb. 30 perc tuti van, mire lefordítja, teszteket nem néztem, lemérni meg nem tudom, nincsenek SBC-im.

Modern BSD-k kernelei dettó, igaz kisebbek, mint a Linux kernel, de vannak azok is annyi millió kódsorosak, hogy nem állnék már le nagyon húgy gépen fordítgatni ilyesmit.

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.”

Pont erről van szó: most ezen a rossz érzésen javítanak valamit - csak így tovább!.

(Anno fordítottam FreeBSD alatt OpenOffice-t - a teljes fordítási ciklus 4-5 nap körül volt. Sajnos volt egy csomó hiba a generálásban, ezek miatt többször futottam neki. És igen, jó érzés volt, amikor sikerült minden hibát elhárítani, és egyben lefordult az egész. Mivel nekem fontos volt, hogy legyen OOo a gépemen, ezért jó élmény volt. Az akkori KDE is hasonló élmény volt (majd egy hétig fodult) - azzal a különbséggel, hogy mivel az sose tetszett, kb. 2x fordítottam, és többet felé se néztem. OOo-t (később LO-t) jóval többször, igaz egy idő után már erősebb gépen.)

Félreérted, ellene én nem vagyok, hogy javítanak rajta, de ez nem sok emberek fog segíteni. Tipikusan a proci lesz gyenge, ahogy már írtam, azon semmi nem fog enyhíteni.

Igen, az OpenOffice/LibreOffice, Chrome/Chromium, Firefox, SageMath, gcc, llvm, stb. elég brutálok, sok órás fordítási idők egy combosabb gépen is, de sok millió kódsor. Linux kernel ezekhez képest még csöppség, de nem annyira, hogy akármilyen ótvar vason érdemes legyen fordítgatni. Lassan már a glibc, mesa is elég vaskos sajnos, és ahogy írod, a KDE se épp röpke fordítási idő.

Lehetni persze mindent lehet, gyenge vason is lefordul, kevés RAM sem gond, mert pótolja swap-pal (ami még tovább lassít), de a végeredményt kínzás lesz kivárni. Ebben a FreeBSD sem lesz másabb sokkal a Linuxnál.

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.”

Egy példa, hogy ma már a 8 giga RAM se sok. Egyik ismerősöm teljesen laikus, vett 1-2 éve egy elfogadható, Lenovo IdeaPad laptopot, Ryzen 3 3200U, 8 giga RAM, 256 giga SSD. Nem acélos gép, de nem is túl ergya. A Win10 frissült neki Win11-re (automata update ugye, a usernek beleszólása nem lehet), meg mellette két vírusirtó (Defender, és a gyártó OEM vírusirtó szutyka, ami alaptelepítésben jött a Win10-zel), plusz az integrált GPU is levesz VRAM-ot a RAM-ból, így marad a 8 giga RAM-ból 3-4 giga szabadon, elindít egy Chrome-ot, vagy egy játékot, rohadt gyorsan elfogy nekik a memória, és lassúvá válnak a dolgok, hiába az SSD. Nyilván Linuxon többet jelentene a 8 giga RAM, de nem a Win11-es (ez utóbbi önmaga megeszik idle-ben 3-4 giga memóriát), ultrabloat, szétvírusirtózott, Chrome memory leakes világban. Pedig ez még teljesen alap felhasználás, nem forgat Linux kernelt.

Ma már szerintem az átlag felhasználónak a 16 giga kezd minimum lenni, Linux, BSD-k alá a 8 is elég lehet. Az alatt ma már senki ne akarjon komolyan akarni semmit.

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.”

Igen, csak O0-val kb. senki se fordít, manapság azért szokás az O2, O3, és még általában az LTO-t is bekapcsolják. Meg ugye az adott utasításkészletre optimalizálás a march=native kapcsolóval. Azért elszüttyög vele egy modern hardver is, főleg, ha ilyen több millió kódsoros épp a kód, combosabb gépen is durva, és a RAM igénye se olyan kicsi, mint gondolnád.

Könnyen ki is próbálhatod, ha van valamelyik gépen egy gcc-d, make allmodconfig-gal fordítasz rajta egy legújabb verziós git/kernel.org kernelt, közben megnézed, hogy mennyi RAM-ot használ.

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.”

Ha jól értelmeztem, akkor a felsorolt 0.5%, 3.7%, 3.8%-ok összeadódnak, tehát a grand total: 8%.

Nyilván ettől nem fog openwrt-s routeren lefordulni a kernel, de azért örülök neki, hogy néha akad valaki, aki megnézi, hogy nem lehet-e itt-ott javítani rajta.

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

Ez sokkal fontosabb a kernel fejlesztők számára, akik számtalanszor lefordítják a kernelt, tesztelés céljából!
Ha nekik megtakarít néhány percet, az a sokszor néhány perc már jelentős.
Amikor én utoljára kernelt fordítottam az jó régen volt, biztosan sokkal több mint 20 éve, de akkor az akkori nem túl gagyi, de nem is erős gépemen, emlékeim szerint elég sokáig futott. És kipróbáltam többféle beállítással, hogy lássam mi az amit fájdalom nélkül kihagyhatok belőle.

Ha ezt naponta sokszor kell megtenni, akkor igenis van értelme ennek a projektnek, még a nagy memóriával rendelkező gépek esetében is.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

A kernel még mindig gcc only? Ha igen, inkább ezen dolgoznának.

Már régóta nem: https://www.kernel.org/doc/html/latest/kbuild/llvm.html

"Distributions such as AndroidChromeOS, and OpenMandriva use Clang built kernels. "

Ha Androidos telefonod van, akkor te is Clang által fordított kernelt használsz.

Úgy kb. olyan hasznos dolognak túnik, mint mikor a neves disztribútor azzal akart kitűnni, hogy az ő disztrója a leggyorsabban telepíthető....

http://www.micros~1
Rekurzió: lásd rekurzió.