Vlákno názorů k článku Kompilace jádra: cesta za nepodporovaným hardwarem od D.A.Tiger - "Vlastní jádro na desktopovém počítači ztratilo smysl před...
-
"Vlastní jádro na desktopovém počítači ztratilo smysl před dlouhou dobou. Výkon i kapacita paměti je dnes taková, že není potřeba odstraňovat nepotřebné moduly, a když se do toho pustíte, jen stěží poznáte, že se něco změnilo."
No nevím... moje zkušennosti říkají něco trochu jiného.
Např na Debianu (distribuci, kterou nejvíce nasazuji a používám) se většinou automaticky instaluje jádro přeložené pro instrukce i686, a to i přesto, že existují buildy i pro jiné - na daném stroji vhodnější - instrukční sady (konkrétně u mě např. core2). Což samo o sobě je hned jedna velká výkonová brzda. Ono je přece jen trochu poznat, když procesor provádí nějakou operaci 10000x/s pomocí tří instrukcí, nebo jen s jednou. Ano procesor to sice zvládne, ale zbytečně se vyžírá jeho čas, který lze potom využít jinde.
Není však ještě vyhráno ani tehdy, když si nainstaluji příslušný build pro daný procesor. Kernel je (alespoň na Debianu) kompilovaný s podporou co největšího množství hw a jeho variací, včetně takových, které nemám možnost v životě potkat. Navíc jsou zapnuty podpory i pro různé hw. konfigurace, např. notebooky, jejichž vypnutí, nejsou-li potřeba, dokáže už docela viditelně urychlit systém. Odstraněním zbytečných modulů a podpor, lze také dosáhnout rychlejšího startu systému - to také není k zahození. Poměrně slušného zrychlení lze dosáhnout i zadrátováním modulů do jádra - Ono zavedení modulu do jádra, až jej potřebuji, je sice hezká idea, ale načítání a následná inicializace taky zabere nějaký ten čas. A navíc některé moduly ke své činnosti vyžadují jiné ( = závisí na nich). Dokonce jsem potkal i hw, který prostě takhle nefungoval. Podle mého názoru je lepší, když si to jádro odbude hned na začátku a pak se s tím už prostě nezdržuje. koneckonců, notebooky a PC-čka zas toho hw tolik nemají, aby většina se dá bez problému "na hulváta" narvat do jádra... :-)
Jinými slovy čím menší a kompaktnější je jádro, tím je systém výkonnější.
A nakonec to nejlepší. Časem jsem přišel na to, že tu je ještě jedna - docela slušná výkonová brzda, totiž API. Konkrétně libC6, která poskytuje základní nízkoúrovňové funkce aplikacím. S trochou nadsázky se dá říci, že je na ni postavené vše nad jádrem. Např, před jejím překladem jsem na HTopu pozoroval jak bývá vytěžováno jedno jádro procesoru téměř na 100%, druhé jelo většinou tak na 4 - 6, max 10%. Zkusil jsem ji zkompilovat na svůj svůj procesor - voalá a už makají obě téměř stejně. Druhou věcí je, že její překlad opravdu trvá, a trvá, a trvá....
A věř mi, že jsem to sakra poznal... Nejen, že rychleji startuje systém, ale třeba i samotný KDE (a je mnohem svižnější), a hodně to bylo poznat i v hrách na Wine ;)
-
Ano, ale o tom píšu také - zmiňuji se o tom, že existují buildy jader optimalizované a nastavené pro konkrétní architekturu. Tam vidím ty brzdy v distribučních jádrech zase trochu jinde.
Ono jde spíš o to, že autor článku píše hned v úvodu, že kompilace a nastavení vlastního kernelu výkon poznatelně nezvýší. Já tvrdím, že to není tak úplně pravda a vycházím při tom hlavně ze zkušeností na desktopech. Jde spíš o to, jestli má cenu, pro konkrétního uživatele (majitele) daného systému, se s tím rejpat...
-
Izak (neregistrovaný)
Blbost, kernel kompilarorem temer ladit nelze ;-)) Ono C se ani moc neladi, nehlede na to, ze dnes ma kazdy 64bit kernel a tam uz se pocita s modernima vecma, jako SSE2 misto mat. koprocesoru etc.
gcc spise ladi c++ a aplikace, takze kompilovat kernel je blbost a to dokonce i na serveru, do bych k tomu musel mit sakra duvod, kdyz dnes uz spise jen dodavam moduly, ktere prikompiluji do stavajici kernelu.
Jediny duvod je specialni server, kde dam klice a nedovolim zavezt nepodepsane moduly, tedy bezpecnost, zase Oracle neuznava support na svoe produkty, pokud tam neni distribucni kernel,a le tak ono to jde udelat i tak, ze to nepoznaji ;-))
No a vykon ohledne odlehceni ;-)) smesne, dnes mame vse v modulech a nenatahuji ty moduly, ktere nechci, dokonce muzu nektere moduly explicitne zakazat, de fakto krom sbernic a jinych veci dnes jiz scripty, co to resi vytahuji nejdrive vse z PNP, APIC a kde ceho, nejedel trva detekce FDD radice, pokud ji zakazete v modulech, ci v parametru bootu, udestrite nejvice casu ;-)))
Vzdyt dnes uz se i SATA modul taha z modulu a nejsme windows, windows natahne vse, co ma v adresari, linux jen to, co sam detekuje, nebo ma v modules.conf a jeho variaci. -
j (neregistrovaný)
Blbosti pises ty, pokud mam v generickym kernelu hafo kravin, ktery nanic nepotrebuju, tak jeho rekompilaci si pomuzu i na serveru - razantne zmensim pravdepodobnost, ze se neco podela, pokud to z kernelu vyhodim.
Nehlede na to, ze kernel je vzdy kombinaci toho co je zakompilovany primo a toho co je modularni a i modul = nejaky bordel v kernelu, ktery jeho nacteni umoznuje. Na serveru kde v 99% nic nikdy nepripojuju je idealni mit naopak naprosto nemodularni jadro - i z duvodu bezpecnosti.
-
trubicoid2 (neregistrovaný)
podivej se na citat od Stevena Rostedta zde:
https://www.abclinuxu.cz/clanky/jaderne-noviny-14.-6.-2012-jak-jadro-rychle-zkouma-retezce
-
j (neregistrovaný)
Porovnani gentoo vs binarni distro na ruznem HW - od AMD na skt A po nejnovenjsi Icka - predevsim na slabsich strojich je kompilace vs binarka casto rozdil mezi funguje to - nefunguje to (napr prehravani videa). na vykonosti systemu jako takoveho, se kompilace specificka pro CPU projevuje tak kolem 10%, ale v nekterych specifickych aplikacich to hodi i 50%+.
Co se jadra tyce, jeho redukce pak velmi vyrazne ovlivnuje prave rychlost startu.
