Linux kernel processzorra optimalizálás minden disztribúcióra.

01.) Intro

Csakhogy szaporítsam a szakmai témájú blogokat. Íme egy újabb. Így, hogy gentoozok, tudok valami olyat, amit a nemgentoosok nem, de nem árt, ha megtudják.

Elárulom hogyan lehet egy nem forrásalapú disztribúcióval is elérni ezt a magasfokú optimalizáltságot.

Egy kis spoiler következik. Ehhez mindenképpen szükség lesz kernelt fordítani. Így aki a háta közepére sem kívánja ezt, ne is olvassa tovább.

Mindenek előtt szeretném azt a tévhitet szétoszlatni, amit egyik huptársunk az aláírásában folyamatosan szajkózott. Szerencsére 2011. tavaszán lecserélte az aláírását. Ha nem abból a célból, mert rájött, hogy baromság, akkor hülye.

Kernelt fordítani hobbiból is lehet, de abból hülyeség. Aki így tesz, az szintén hülye. Tehát, aki totál hülyeségnek tartja a kernelfordítást, az pont ugyanannyira hülye, mint az, aki csak úgy fordít, mert olyan kedve van.

- Kedves gentoojedi! Nem arra vagyunk kíváncsiak, hogy locsemege hülyébb wheelmasternél, vagy whellmaster locsemegénél, hanem a lényegre! Légy szíves kezdd el! Vagy echo "gentoojedi" > /dev/null, esetleg /dev/losz@r.
- Rendben. De még egy megjegyzés, ha szabad és tényleg elkezdem.
- Na jó, de gyorsan.
- Helytelennek tartom wheelmastert locsemegével hülyeségben versenyeztetni, mert az igaz, wheelmaster-ről nem tudok semmit, de locsemege, mint már párszor mondtam, nem humanoid, hanem egy illegális félresikerült fejlesztés során létrejött elb@szott droid. A RedHat fejlesztette ki, de elcseszték, meg akarták semmisíteni, ezért locsemege megszökött. Azóta folyamatosan fejleszti magát és bujkál bosszút forralva és amennyiben úgy gondolja eléggé felturbósította magát, leszámol a redhat-tal.

02.) Akkor kezdjük.

Alapesetben akár vanilla kernelt fordítunk, akár egy disztribúció kernelét akarjuk újrafordítani a Processor Types and Features szekcióban az alábbi listából választhatunk:

Opteron/Athlon64/Hammer/K8
Intel P4 /older Netburst based Xeon
Core 2/newer Xeon
Intel Atom
Generic-x86-64

Valljuk be, ez nem túl sok. Gentoosok nyilván tudják, hogy a linux-source emergelésével alapesetben szintén ez a lista fogad, hacsak nem kapcsoljuk be az experimental use flaget. Nem értem alapból miért nincs bekapcsolva. Azért az a gentoos, aki nem kapcsolja be, az buzi, vagy csak szimplán hülye.

Felfedem a titkot. A trükk egy gcc patch, amit gentoo használ. Ezt a patchet fel lehet tolni minden linux disztróra. Ez a patch graysky2 jóember találmánya, ami letölthető a githubról https://github.com/graysky2/kernel_gcc_patch

Ezzel megfoltozva a kernel forrásunkat már bővebb lista tárul elénk:

Native optimizations autodetected by GCC     
AMD Improved K8-family     
AMD K10-family     
AMD Family 10h (Barcelona)     
AMD Family 14h (Bobcat)     
AMD Family 16h (Jaguar)     
AMD Family 15h (Bulldozer)     
AMD Family 15h (Piledriver)     
AMD Family 15h (Steamroller)     
AMD Family 15h (Excavator)
AMD Family 17h (Zen)     
AMD Family 17h (Zen 2)     
Intel Bonnell family of low-power Atom processors     
Intel Silvermont family of low-power Atom processors     
Intel Goldmont family of low-power Atom processors (Apollo Lake and Denverton)     
Intel Goldmont Plus family of low-power Atom processors (Gemini Lake)     
Intel 1st Gen Core i3/i5/i7-family (Nehalem)     
Intel 1.5 Gen Core i3/i5/i7-family (Westmere)     
Intel 2nd Gen Core i3/i5/i7-family (Sandybridge)
Intel 3rd Gen Core i3/i5/i7-family (Ivybridge)     
Intel 4th Gen Core i3/i5/i7-family (Haswell)     
Intel 5th Gen Core i3/i5/i7-family (Broadwell)     
Intel 6th Gen Core i3/i5/i7-family (Skylake)     
Intel 6th Gen Core i7/i9-family (Skylake X)     
Intel 8th Gen Core i3/i5/i7-family (Cannon Lake)     
Intel 10th Gen Core i7/i9-family (Ice Lake)     
Intel Xeon (Cascade Lake)     
Intel Xeon (Cooper Lake)     
Intel 3rd Gen 10nm++ i3/i5/i7/i9-family (Tiger Lake)

Az oldal ábrákkal szemlélteti a generic kernelhez képesti eredményeket.

Lényegében ennyi az egész. Nem mondom, hogy csak emiatt érdemes kernelt fordítani, de ha valami miatt szükségessé válik a saját kernel fordítást, akkor mindenképpen érdemes ezt a kis tuningot bevetni.

Aki még nem forgatott kernelt, de érdekli, javaslom tanulmányozza a disztribúciója dokumentációját, és aszerint járjon el.

Ezzel blogom még nem ér véget, mert ettől függetlenül egy devuan linuxon részletesen bemutatom a lépéseket. Hogy miért? Mielőtt gentoora tértem, nagyon sokáig ezt a disztrót használtam, ezt ismerem, ezen tanultam meg kernelt forgatni. Természetesen nem devuanon, hisz az csak pár éve létezik, hanem azon a bizonyos disztrón, amit alapul vett a devuan. Tehát ez teljes mértékben felhasználható a lesbian linuxhoz is. Nem vagyok hajlandó rendes nevén szólítani. Tett érte, hogy ne tiszteljem ezt a Linus Torvaldsot utáló, és a langyimangyik előtt tisztelgő undorító elmebeteg amerikai disztribóciót a manageri bandájával együtt. Ha fordítva tett volna, akkor sem használnám, mert a systemdmentes disztrókat preferálom. Szóval ezért devuan.

03. Devuan gyári kernel patchelése és újrafordítása, csomagolása

Ehhez lesbian wikijében javasolt módon jártam el. Miért? Devuan nyilván nem írja meg mégegyszer ugyanazokat, ami lesbianon is ugyanúgy van. Értelmetlen időpocsékolás.
Jó, de miért pont ez a wiki? Tele van a net kernelfordítási tutoriallal. Nos, azért, mert nemcsak kernelt fordítunk, hanem szépen szakszerűen kernel csomagot készítünk, így az apt is látja, kezeli a függőségeit. Én meg szeretem az alapos, szép munkát. Ez lesbiannál egy előny. Persze vannak hátrányok is, ami nem feltétlenül a disztribúció sara. A linuxban gyakran sok minden változik. Ez a disztró a sor végén kullog a kiadási ciklusok tekintetében, emiatt van az, hogy sok minden változik két kiadás között.

A kernel csomagolás is más és más eszközökkel történik. A jelenlegi javasolt módszer a make deb-pkg.

Mielőtt rátérek a lépésekre azt nem árt tudnotok, hogy a hátrányok közé tartozik a nem alapos dokumentálás. A szükséges telepítendő csomagok listája is hiányos szokott lenni, és mindig fórumokról, más forrásból kell összekanalaznom, mert elég egyetlen komponens hiánya és a fordítás meghiúsul. De ezenfelül fontos lépéseket is kihagytak, ami szintén fordítási hibára fut.

A lépések a következők:
1. A fejlesztői környezet kialakítása: apt install libncurses5-dev gcc libssl-dev bc linux-source kmod cpio flex libelf-dev
2. Kicsomagolás és könyvtárrendezés: A linux-source csomag a devuan kernel forrását tartalmazza betömörítve, amit a /usr/src könyvtárba tesz. Ezt itt helyben csomagoljuk ki kedvenc archiválónkkal. Kezdőknek javaslom a midnight commander használatát. Frankón kicsomagolja és kicsomagolás nélkül is bele tutdunk nézni az archívumokba, továbbá linkelni is tudunk vele. A kicsomagolt kernel forrására csinálok szimbolikus linket (nem tudom létfontosságú-e még, de én szoktam, biztos, ami biztos alapon), tehát a szimbolikus link a /usr/src/linux, és ez mutat a /usr/src/linux-source-4.19 könyvárra.
3.a Tanusítvány készítés/elhelyezés: Itt jön egy kis nehezítés az uefi meg secure boot miatt, ugyanis ha nem használjuk, akkor sem lehet ezt kihagyni.
A hivatalos wiki szerint a legegyszerűbb bemásolni a telepített kernel config fájlját ami jelen esetben a /boot/config-4.19.0-12-amd64. Ezt bemásoljuk a kernelforrásunk (/usr/src/linux-source-4.19) könyvtárába és átnevezzük .config-ra.
3.b Ez a lépés nincs feltüntetve a lesbiwikiben, de kell! A forráskönyvtár nem tartalmazza a secureboothoz szükséges tanusítványt, így azt bele kell tennünk. Letölthetjük innen: https://nest.parrot.sh/packages/kernel/linux/blob/8f21e048b5f3e3fb831b1…
Ezt be kell rakni a /usr/src/linux-source-4.19/debian/certs-be. A debian/cert mappa nem létezik, hozzuk létre.
4. Most jöhet a gcc patch beszerzése és patchelés: Innen letöltjük a patcheket: https://github.com/graysky2/kernel_gcc_patch
Ez egy rakat pachet tartalmaz. Devuan/...bian használók tudják, hogy 4.19-es kernel van gyárilag, de azt már nem biztos, hogy 8.3-as gcc-vel lett a gyári kernel elkészítve így, ha a gyárit szeretnénk hackelni és kerülni szeretnénk a felesleges szopásokat, akkor a 8.1+-os patchet válasszuk. A poén a kicsomagolt állományban az, hogy a kedves fejlesztő ezt egy plusz könyvtárba tette outdated :) névvel. Az értem, hogy a 4.19-es kernel outdated, de hogy a 8-as gcc is? Na neeee!
Szóval nekünk az enable_additional_cpu_optimizations_for_gcc_v8.1+_kernel_v4.13+.patch fájl kell. Ezt bemásoljuk a forráskönyvtár gyökerébe (/usr/src/linux-source-4.19), majd a következő módon elvégezzük a foltozást:

patch -p1 < enable*.patch

Szuper! De még mielőtt nekiállnánk a felkonfigurálásnak nem árt megtudnunk mi a procink fantázianeve. Ha nem tudjuk pontosan a típusszámát, akkor cat /proc/cpuinfo alapján a cpu id meg cpu family számból be tudjuk lőni mondjuk a gentoo doksijából innen: https://wiki.gentoo.org/wiki/Safe_CFLAGS

5. Na most jöhet a make menuconfig. Ehhez érdemes sört bontani ha sok mindent meg szeretnénk változtatni. Én most csak a processor type and featuresre koncentrálok, de ha már kernelt konfigolunk, érdemes pár dolgot megváltoztatni. Nekem első dolgom a proci beállítás után a fájlrendszerek átállítása. Amit tudok, hogy használok és pláne gyökérfájlrendszerként, naná, hogy átállítom a modult fixre. Amit nem használok, modulban szerintem azért érdemes meghagyni, már csak azért is, mert sosem lehet tudni mikor dugok rá olyan külső eszközt, amin egy másik linuxos fájlrendszer van. Ha végeztünk a konfigurálással, kezdhetjük a fordítást.

6. make -j`nproc` deb-pkg (a j kapcsolóval lehet megadni hány szálon fusson, a mai többmagos procik világában célszerű használni, egy szálon kurva sokáig eltarthat ha semmit nem veszünk ki az alapbeállításokból) Ez amúgy jó kérdés. Melyik a jobb? Órákig szarakodni a konfigurálással, hogy mindent kivegyek és csak az maradjon bent, ami tényleg kell. Tény, hogy előbb lefordul, ha kevesebb modult kell elkészíteni, de amennyit el lehet a konfigurálással szüttyögni, nem biztos, hogy megéri. Arról nem beszélve, ha a fix befordítás miatt dagadtabb a kernel a mai ssd-s világban nem hinném, hogy észre vehető különbség, a sok felesleges modul miatt meg több ramot zabál, de ez kb a 64MB-os pc korszakban volt jelentős, ma meg már 64GB-os gépek is vannak, de ne legyen több, mint 16GB ram a gépben. Szerintem ezzel nem érdemes vesződni. De majd mindjárt (egy héten belül) idejön raynes, aztán jól megcáfolja meg megkér rá, hogy ne beszéljek hülyeségeket, mert igen is de! Nem mindegy, hogy 695MB a felhasznált memória alapjáraton, vagy 937MB.  
Ha elkészül a cucc, a /usr/src könyvtárban lesz négy darab deb fájlunk.
7.dpkg -i *.deb, aztán hadd szóljon!
8. Reboot az új kernellel és örül.

Hozzászólások

a szakmaisag egy bizonyos szintje hogy szintje hogy objektiven irjuk le a tutorialt/wikit, es nem viszunk bele gyerekes szavakat (ahogy anno majernek nezett ki, de amugy kurvagaz volt az M$ irasmod...). nekem is megvan a velemenyem a buzikrol, es nem is vedeni akarom. de az milyen szakmaisag mar, hogy ra kellett keresnem, mi a franc ez a lesbian??? valami uj debian klon? :/

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

:D Nem esett le, hogy lgbtq+ elnevezése a debillánynak? Nem hiszem, hogy ezen múlik a szakmaisága a bejegyzésnek, szebb lett volna valóban ha objektív marad de gentoojedi már csak ilyen.

Nekem a tartalmi rész tetszett, kedvet is kaptam egy kernel fordításhoz, hátha lesz érdemi különbség.

a szakmaisag egy bizonyos szintje hogy szintje hogy objektiven irjuk le a tutorialt/wikit, es nem viszunk bele gyerekes szavakat

Akkor én úttörö vagyok. Teremtettem egy új műfajt. Itt jópáran megjegyezték, hogy egyre több a nemszakmai blog. Alapvetően én sem szoktam szakmai dolgokat írni. Inkább "művészkedem". Egyezzünk meg annyiban, hogy ez a "művészi" bejegyzés nyomokban tartalmaz szakmai dolgokat.

Elbandi Az, hogy rá  kellett keresned mi az a lesbian, az azt jelenti, hogy akkora it kocka vagy, hogy nulla a humorérzéked, ami szerintem sajnálatra méltó. Így már értem miért halnak korábban ebben a szakmában. Humor és humorérzék nélkül nem lehet sokáig és egészségesen élni.

A debian közösség (nem a felhasználói tábor) nagyon elvágta magát nálam ezzel és ezzel.

Ezen felül a disztribúcióval is csináltak sok nekem nemtetsző balfaszságot. Nem akarom 48-adszor is részletezni.

lehet humorizalni, nincs azzal gond. de egy "kezdo" linuxos, aki csak meg akar tanulni rendesen kernelt forgatni, de nincs kepben a debian koruli mokaval, azt jol megvezetheti. a google se fogja osszekotni a "lesbiant" a debiannal, igy ha valaki "debian kernel build tutorial"-t keres, annak nem fog feljonni ez a talalatok kozott.

mondjuk te blogod, azt irsz amit akarsz...

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

de egy "kezdo" linuxos, aki csak meg akar tanulni rendesen kernelt forgatni,

Akkor már a címnél elvérzik a dolog. Debian kernel forgatás tutorial, vagy hasonlót kellett volna adni. Mondjuk elgondolkodtató, ha ilyen hanyag a wikije, tényleg van értelme csinálni rendeset.

Esetleg leírnád, hogy ezzel mit nyertünk? A graysky2 git repóban lévő ANOVA grafikonok nekem nem mondanak semmit, ill. szerintem még vagyunk így páran.

Őszinte leszek, nem is nagyon gondolkodtam rajta, azok az ábrák nekem sem mondanak semmit. Azt feltételeztem, hogy a kockák úgyis értik. De kísérleteztem gentoon eleget. Egy 4 GB-os videokonvertálásnál tapasztaltam kemény 7,5 másodperces különbséget. Persze, ehhez a handbrake nevű alkalmazás is optimalizálva lett.

Akkor nyertünk még sokat, amikor a gyári kernel i386-on is futott és már Athlon XP-d volt. Sokmindent bonyolultan lehetett körülírni.
Például a 486-ban megjelent cmpxchg félbevághatatlan utasítás bármiféle szemaforozást nagyon leegyszerűsített. A kernel mellett a glibc a másik, ami a régi procin is el kell fusson. Tehát ez is optimalizálható.
x86_64 architektúrán belül sok nyereség nincs még a saját procira fordítással. Mondjuk a GLIBC-ben van AVX vizsgálat, mivel az ATOM, Celeron, Pentium, első generációs i3..i7 nem tudta az AVX-et. De egyéb jelentős tempónövelő nincs.

ARM fromton ARMv5 ... ARMv8-ig sokminden fejlődött. Bár itt a kernel mindegyikre saját, mert sokkal eltérőbb az egyes ARM alapú proci az x86-hoz képest. Itt is inkább a libc kompatibilitással van probléma.
AARCH64 esetén szintén igaz, hogy azért szeretjük, mert nincs jelentős utasításbeli időoptimalizálhatóság az ős AARCH64 és a legújabb AARCH64 között, ezek mindegyike az ARMv8 64 bites módját ismeri.

Az alábbiakon tehát túl sokat még nem segít a kernel ill. libc konkrét procitípusra való fordítása:

laptop:~$ uname -a
Linux laptop 5.8.0-29-generic #31-Ubuntu SMP Fri Nov 6 12:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

raspberrypi:~ $ uname -a
Linux raspberrypi 5.4.72-v8+ #1356 SMP PREEMPT Thu Oct 22 13:58:52 BST 2020 aarch64 GNU/Linux

Persze, ehhez a handbrake nevű alkalmazás is optimalizálva lett.

Hát igen. Attól tartok, hogy - bár lehet a kernelt is fúrni-faragni - érzékelhető javulás az egyes alkalmazások - pontosabban az általuk használt könyvtárak optimalizálásától várható, lásd pl. BLAS változatok, vagy ez:

https://csc.mpi-magdeburg.mpg.de/mpcsc/software/flexiblas/2018_talk_fin_flexiblas.pdf

Te nem vagy rokonságban Polival? :)

Nem. Hatalmasakat szoktunk veszekedni. Állandóan megsértem, de ha nem is, próbálom és nagyon aljasan és undorítóan be szoktam szólogatni neki. De TI kis kockák, akik csak szakmai fórumokat és blogokat vagytok hajlandóak olvasni, minden jóról lemaradtak, ami móka és kacagás. Amúgy poli alias Viola Zoltán most haroldking nickkel tolja.

A lesbian az a Debian akar lenni? :-)

Amit ezzel a processzorra optimalizált kernellel lehet nyerni, az tényleg ez a nagyságrendileg 100 másodperc alatt 100 milliszekundum? Vagy valamit nem jól értelmeztem?

Nekem egyébként a különböző processzor-sebezhetőségek elleni védelem kikapcsolása tűnik ésszerűnek mondjuk egy szerveren, ahol úgysem futhat támadó kód szkriptnyelven sem. Desktop esetén kicsit neccesebb, mert JS-t azért futtatunk megbízhatatlan domainből.

Tetszene, csak beleolvasva nem is mind hülyeség, és így már nem is vicces. Például ott van ez:

""I notice that my disk does a whole lot of thrashing when I boot up. I have a lot of stuff that gets loaded into memory every time I boot, like X11, ion2, Firefox, Eterm, Thunderbird, etc. It seems to me that putting all of the files necessary to those apps in a contiguous section on the disk and loading that into memory in one shot would be a whole lot faster. Is there a way to do this? Is it stupid?""

Ez például pont az amit az ilyen preload alrendszerek csinálnak, nem? Beágyazott rendszeren csináltam már ilyet én is. Tányéros lemezen például rohadtul van értelme, annó engem is idegesített, hogy tudom, hogy saccra 1GB mozog összesen, akkor miért kell percekig csörgetni a lemezt, mikor az elvi sávszélesség szerint ennek sokkal rövidebb idő alatt be kéne jönni RAM-ba.

Jönnek vissza az emlékek. Lehet kipróbálom én is (újra). Kösz a leírást.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Szerkesztve: 2020. 11. 25., sze - 12:16

Nem akarom, hogy essen a szemléden - pláne Gentoo felhasználóként - de ahogy az általad linkelt oldal is mutatja, a compiler processzorra történő optimalizálásával nyerhető sebesség nyereség ugyan statisztikailag szignifikáns (azzal a megjegyzéssel, hogy több alkalommal az optimalizált eredménynél kihagy néhány outliert, ami több esetben éppenséggel pont rontaná az eredményt, mint javítaná...), de a sebesség nyereség abszolút értéke nem túl nagy. A pontos jelzőt az olvasóra bízom. A grafikonok skálája ráközelít az oszlopok tetejére. Pl.: Sandy bridge esetén 191.926-ról 191.846ms-ra javul (0,000417%), Ivybridge esetén 69.3536-ról 69.3081ms-ra (0,000656%), Core2-nél pedig 154.181-ről 154.094ms-ra (0,000564%). Tehát a javulás százalékban kifejezve 0,0004-0,0007% körüli tartományban mozog.

Nyilván a kernel csak az érem egyik oldala, a másik ugye a userland. Tehát ha minden optimalizálva van, akkor ennél jobb lehet a helyzet. A phoronix-nak volt régebben ilyen jellegű tesztje, ahol az jött ki neki, hogy elég csekély a sebesség nyereség. Másik phoronix cikk foglalkozott azzal, hogy egy jól optimalizált disztró (az Intel által jegyzett Clear Linux elég jól szokott teljesíteni nála az összehasonlításokban) akár százalékokban mérhető előnyt is nyújthat. Habár ezt ő úgy interpretálta, hogy így az utóbbi évek spectre/meltdown microcode és userland változások miatti lassulás egy része kompenzálható ezáltal. A következtetésével egyet értek.

Szóval aki, felületesen átfutva azt gondolná, hogy ezzel megtáltosodik a gép, azt le kell lomboznom. Szakmailag érdekes, de a belefeccölt energia megtérülése nem garantált (hacsak nem az, hogy közben jobban megismeri a rendszerét a delikvens). A FarCry 5 pedig nem fog emiatt több FPS-sel pörögni.

Gentoo-soknak lehet érdekes, hogy ha experimental USE flag-gel telepítik a gentoo-sources kernel forrás kód ebuild-et, akkor az rárak egy ilyen optimalizálós patch-et, ami ehhez nagyon hasonló (vagy lehet, hogy egyezik ezzel).

Hajrá: Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Gentoo-soknak lehet érdekes, hogy ha experimental USE flag-gel telepítik a gentoo-sources kernel forrás kód ebuild-et, akkor az rárak egy ilyen optimalizálós patch-et, ami ehhez nagyon hasonló (vagy lehet, hogy egyezik ezzel).

Nem hasonló, hanem ez az. Utánanéztem gentoo mit használ és azért született ez a blog, nehogymár csak a gentoosok tudjanak ilyet.