Zsugorodó x86 stack

Címkék

A kernel stack (verem) az x86 rendszereken két oldal (pages) hosszú, azaz 8KB-os. Ez a verem terület minden egyes processzhez létrejön; így könnyen belátható, hogy egy olyan rendszeren, ahol sok processz fut, a stack által felhasznált memória mennyisége túl nagy méreteket is ölthet.Ez a memória nem lapozható (azaz nem írható ki (swap-out) és nem olvasható vissza a diszkről (swap-in). Ami szintén szükséges hozzá, az az "order one" (két oldal) allokáció, minden egyes processzhez. Amint a memória fragmentálttá, töredezetté válik a több-oldalas allokáció egyre nehezebb lesz, és bizonyos processz számot elérve az új processzek létrehozása meghiúsul. Szóval ezen okokból, szükségessé válhat, a stack méretének csökkentése.



Dave Hansen postázott egy foltot (eredetileg Ben LaHaise foltja) amely levágja a processzenkénti kernel stacket egy oldalra (single page - 4KB). A patch, hogy ezt meg tudja valósítani az alábbi dolgokat teszi:

- Tartalmaz egy opciót, amely lehetővé teszi, hogy csökkentsük a kernel stack méretét - természetesen ez magában hordozza azt, hogy a csökkentett méretű vermet sokkal könnyebb túlcsordítani (overflow) ezért ez a lehetőség nem áll mindenki előtt nyitva

- A folt tartalmaz debug részeket, hogy ezeket a túlcsordulásokat figyelni lehessen, és a gcc profiler funkcióival ellenőrizni lehessen a verem állapotát.

- Az interrupt (megszakítás) kezelés is saját igényeket támaszt a stack-kel szemben. A folt külön választja a per-processz és a per-CPU vermet.

A folt egy variánsa már keringett a listán előzőleg is, Linus még nem kommentálta. Kérdéses, hogy a feature freeze után ez bekerülhet-e a 2.5-ös kernelbe.

Hozzászólások

Hali!

Nekem ugy tunik ennek csak embeded rendszereken van jelentosege.

Laci

10.000 azaz tizezer processz ?!?!?!

huuh. az valami atom brutal cucc lehet. Es ez hany processzoron? Egy PC ezzel meg siman eltrashingel a hosszu processz valtasi ido miatt.

Szerintem az lenne a legjobb, ha ezeket a vedett uzemmoddal kapcsolatos dolgokat a leheto legrugalmasabban konfiguralni lehetne.

pl a heap-stack-gap, meg a hasonlo aprosagokra is nagyon jo lenne a juzer konfigolhatna hogy az o futasi kornyezeteben hogyan nezzen ki. (talan jo lesz majd erre a UML, csak legyen mar stabil, hogy ki merjem probalni... )

Laci

Lásd régi ftp.cdrom.com. Volt olyan időszak, amikor 10000 konkurrens FTP kapcsolatot szolgáltak ki vele.

A gép mellesleg egy 550 MHz-es PIII Xeon volt, 4 GB memóriával és FreeBSD-vel.

Sajnos az FTP felhasználókról készült MRTG grafikont már nem találom, de azon látszott, hogy egy kis ideig több mint 6000, majd (nyilván kicsi volt a gép) huzamosabb ideig 6000 párhuzamos FTP kapcsolatot szolgált ki. (Az előtte lévő gép, egy 200 MHz-es Pentium Pro 3600-as userlimittel ment, ha jól emlékszem 512 MB memóriával).

Hazai példát is tudok mutatni (igaz jóval szerényebb): ftp.fsn.hu FTP kapcsolatok