4K stacks alapértelmezetten?

Kernel

Andrew Morton egy, a 4K stacks-t a mainline kernelben x86-on alapértelmezetté tevő commit üzenetre válaszolva azt írta, hogy "ez a patch a kernelek összeomlását okozhatja". Molnár Ingo erre azt válaszolta, hogy "melyik mainline kernelek omlanak össze és hogyan fognak összeomlani? A Fedora és más disztrók évek óta használják a 4K stacks-t.". Majd hozzátette, hogy több tízezer felbootolási tesztet végeztek mindenféle driver-rel és engedélyezett kernel opcióval és nem volt problémájuk a 4K-s stack méret miatt. Szóval, a változtatással a mainline kernel csak a disztrók jelenlegi alapértelmezett beállítását követné.

Válaszként felmerült, hogy ha Ingo a "más disztrók" alatt a RHEL-t érti, akkor OK, de az openSUSE, az Ubuntu és a Mandriva még mindig 8K-s stack méretet használ.

A témával kapcsolatban indult hosszas vitában megemlítésre került, hogy az nfs+xfs+raid kernelkonfigurációk és az ndiswrapper használata okozza legtöbbször a 4K méretű stack túlcsordulását.

A stack alapértelmezett mérete x86-on a mainline kernelben 8K. Mivel minden processzhez/thread-hez allokálódik kernel stack, a memóriacsökkentés egyik módja lehet a 8K stack megfelezése. Továbbá, a 8K stack-es működés két, fizikailag folyamatos page-t igényel, s ezt a követelményt egy működő rendszeren nehezebb lehet teljesíteni a fragmentáció miatt.

Andi Kleen megkérdőjelezte a 4K stack méret hasznosságát, mondván, hogy amennyire ő tudja, a 4K stacks-nek nincs sok értelme a 2.6-os kerneleken. Ismeretei szerint a 4k stacks-nek a 2.4-es kernelek "szar" virtuális memória alrendszereivel (VM) volt értelme, de azok az idők már elmúltak.

Arjan van de Ven megjegyezte, hogy a 2.6-os kernel VM implementációja jóvan fejlettebb, de a 8K stack-kel előálló fragmentációs probléma nincs megoldva.

A 4K stack méret mellett és ellen számos érv hangzott el. A KernelTrap cikke a témában itt olvasható.

( trey | 2008. 04. 24., cs – 10:35 )

"de az openSUSE, az Ubuntu és a Mandriva még mindig 8K stack méretet használ."

És tényleg, az Ubuntu még mindig 8K-t használ: 


root@alderaan:/home/trey# grep 4K /boot/config-2.6.24-16-generic          
# CONFIG_4KSTACKS is not set

--
trey @ gépház

( uid_4263 v | 2008. 04. 24., cs – 10:43 )

Nem magának az ndiswrapper -nek van vele gondja, hanem azoknak a 2000/XP wifi drivereknek, amelyeket betölt (megpróbál betölteni). Lefordul és modprobe -olhatja is az ember 4k stack kernelen, csak figyelmeztetést ír ki, hogy a wines driverek nagy részének gondot fog okozni.

http://gyuszk.homelinux.org

-- There is never time to do it right, but always time to do it over.

( uid_228 | 2008. 04. 24., cs – 10:44 )

nfs+xfs+raid

NFS XFS fölött? Öhöö, ezt hívják extrémsportnak. :)) Már a részletekre nem emlékszem, de nagyon megszívtam anno vele.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Jah. Nehany szaz ami RHEL4-ia32, es nem is fog erezhetoen csokkenni a kozeljovoben, sot. Tobb ezer regebbi ia32-es RHEL-t kellene migralni, de valahogy nem surgos a dolog, mert senki sem akar massziv uzemeltetesi problemaba belefutni. Inkabb legyen memoriafragmentacio, es rendszeres ujrainditas, mint veletlenszeru, de tomeges elszallas.

S helyette mi lesz? Maga az XFS amugy jo, s most, hogy mondjatok a kis hazi szerver (swraid+xfs+nfs) neha misztikus korulmenyek miatt szetfagy:) sajnos headless, szoval nem szoktam kernel panic feliratokat lesni rajta, de lehet, h eztan megteszem.
Kis fileokra sajna tenyleg nem tul jo, de sztm hazi hasznalatra sem feltetlenul. Ha jol tudom inkabb sok parhuzamos diszkmuvelet eseten mutatja ki a foga feherjet (tehat inkabb szerverben hasznos).

szerk:ok, nem olvastam eleg okosan, reiser lesz helyette mar latom:)

Elég brutálisan hangzik.
Szerintem ahova ilyan kombó kell oda már olyan vasat kell tenni, ami minimum a "raid" részét kiváltja.

Üdv,
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."

( wildy | 2008. 04. 24., cs – 11:24 )

A cegnel kemenyen szivunk a 4K-s stack miatt, a RedHat meg mindig masokra mutogat. Szoval a "nincs bejelentes, hogy gond lenne a 4K stack miatt" enyhen szolva nem allja meg a helyet.

akkor megoldás, amit anno fedora alatt csináltam, hogy distro-kernel-src leszed és kernel újraforgat 8k-val

Persze. Ezzel lottek is a tamogatasnak.

Hiaba kaptak egy rakas kernel oops-ot, stack analizissel, elzarkoztak tole.

Hát :-) Még jó, hogy van támogatás.

Igaz, a hibától elzárkóznak, és rendszeresen borulnak a gépek...

Fene tudja. Szerintem ha nekem ilyen problémám lenne, és ilyen support, valamit változtatnék. Pl. vendort.

Nem lehet, hogy jobb lenne újrafordítani? Igaz, hogy ez a csodálatos támogatás megszűnne, viszont esetleg nem borulnának a gépek, és nem lenne miért igénybevenni a támogatást :-D

Egyébként milyen dolgok miatt szoktátok a támogatást igénybevenni? És milyen gyakran?

Mert gondolom, ha a kernelt újrafordítod, attól még a többi programra a támogatás nem szűnt meg.

G

20k szerverrol beszelunk, irdatlan sokfele hardveren, amelyek mindegyikere kapunk tamogatast a RedHat-tol. Ha kell, elmennek ok a hw-gyartohoz (IBM, HP, Dell, Qlogic, Broadcom, ...). Ezt nem lehet felvallalni, csak irdatlan raforditassal mind emberi, mind anyagi oldalrol. A gepeken futo programok donto tobbsege vagy hazon belul keszul, vagy RHEL-en bevizsgalt a fejlesztoje altal.

( gee v | 2008. 04. 24., cs – 11:34 )

Miért kell két fizikailag egymás mellett levő page?

Nem az lenne a VM feladata, hogy találok két lapot a fizikai memóriában itt és amott, és az a program (a processzor) számára úgy tűnik, mintha egymás után jönne?

A túlcsorduláshoz meg: nem lehetne kidolgozni egy mechanizmust, amivel ha egy program telinyomja a 4K-t, akkor kapjon még négyet? De max. 8-at?

Így ha futtatok 100 processzt, nem pazarlok el 400K memóriát (ami a teljes fizikai memóriám kevesebb, mint fél ezreléke), de ha valami nagyétvágyú processz jön (pl. NFS), akkor sem omlik össze a világ

G

Szerintem nalad a pont, ott hogy kevesebb mint fel ezreleke. Manapsag mar 400Kn nem veszunk ossze szerintem. Nyilvan bizonyos helyeken jol jon a 4k, rakjuk at a kernel hackingbol a for small systems menupont ala, es kesz.

Szerk: elolvastam a kerneltrapos cikket is, de meg mindig nem gyoztek meg.

Nade miért okoz fragmentációt? Mi fragmentálódik? És hogyan?

Miért speciális a heap? A proci az MMU-t kikerülve fér hozzá? Vagy mi?

Miért nem tudja a memória management külön lapokból összerakni itt-ott?

Ha letette valahová, miért nem tudja a lapot máshová átdobni?

Egyébként pedig mi az, hogy fragmentáció? Attól, hogy a fizikai memória közepén itt-ott van 1-2 foglalt lap, ami éppen heap, a többi lapot még a processzor simán egyben tudja látni, az MMU a fizikai memóriát elrejti előle.

Nem?

Bizonyára valami alapvető dologra már nem emlékszem, vagy visszafejlődtek a procik, vagy mittudomén.

A linux kernelben ez ugy mukodik, hogy alapvetoen ketfelekeppen foglalhatsz memoriat. Az egyik a slab allocator, amit a kmalloc-al ersz el, aminek egyik jellemzoje, hogy fizikailag folytonos teruletet allokal, ami egyreszt azert jo, mert gyors, masreszt mert jobban cache-elheto (tehat megintcsak gyors :) ).
A masik lehetoseg a vmalloc, ami pontosan azt csinalja, amire te gondolsz, cserebe lassabb (altalaban csak a jo nagy dolgok tarolasara hasznaljak).
A processzek kernel-stackjenek az alloc_thread_info() foglalja a memoriat, ami pedig (i386-on) a kmalloc-ot hasznalja, igyhat ehhez a muvelethez kell az a 2, egymas melletti page.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

csak tipp
konkretan folyik a verseny, hogy egy processz kreacio mennyi ido. Es CPU tick darabban merik, nem masodpercben.a kernelthread kreacional szinten. "most akkor melyik nonblocking syscall teremt maganak ujabb kernelthreadet vagy melyik nem" jellegu szorozesen.

a 4k (1 lap) kernelstacknek a kovetkezo elonyei vannak:
- gyorsabb a kernelthreadkeszites (1 lapot gyorsabb foglalni, mint kettot. Ket egybefuggo lapot gyorsabb foglalni, mint ket fregmentaltat stb) igy gyorsabb lesz a processz kreacio is
- a tulsagosan bonyolult kernelen beluli hivasi lanc, vagy a rekurzio hamarabb kiderul, annak letisztitasaval hosszutavon a kernel gyorsabb (jobb) lesz
es a kovetkezo hatrannyal:
- a jelen pillanatban a meglevo nagy stackhasznalok miatt az instabilitasi faktor nagyobb

BOX!
:-)

( padawan | 2008. 04. 24., cs – 16:28 )

En ugyan mezei desktopuser vagyok de kb a 2.6.20-as szeria eleje ota 4Kstacksem van es soha semmi gond nemvolt vele.
Mellesleg, mint mar emlitettek, akinek nemtetszik/nemjo forgasson kernelt.

( vb | 2008. 04. 25., p – 10:07 )

Egyébként i386-os architekúrán miért 4K a PAGE_SIZE ?
Írtam drivert más archiektúrán futó linuxra, és ott 8K volt a lapméret, a memória méret pedig 32 MB.
Csodálkoztam, pont fordítva lenne értelme.