Diskuze o 4K zásobnících v jádře

Rozvinula se diskuze o zavedení 4K zásobníků v jádře (namísto současných výchozích 8K). Řešilo se především riziko pádu systémů po této změně, i když je 4K už roky výchozím nastavením na Fedoře a jiných distribucích. Čtěte KernelTrap.

23.4.2008 11:25 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[stulda]

Jake to ma vyhody?

[Luk]

Výkonnostní. Když je paměť hodně fragmentovaná, může nalezení dvoustránkového bloku paměti pro zásobník chvíli trvat. Když má zásobník velikost jedné stránky, lze použít hned první volnou stránku, což je mnohem rychlejší.

[stativ]

I při alokaci velkých rozsahů paměti?

[Luk]

??? Nerozumím... Při jaké alokaci velkých rozsahů paměti? Jde o alokaci paměti pro zásobník jádra. Velké rozsahy fyzické paměti se běžně nealokují (jen např. při inicializaci ovladače, který potřebuje velký buffer - ale ani pak to není více než 128 KB). Velké rozsahy virtuální paměti se alokují po jednotlivých stránkách.

[stativ]

Aha, už to chápu. Já měl za to, že to má něco společného s virtuální pamětí.

[Xerces]

Nevite nekdo, jen pro zajimavost, proc tam teda nastrelili puvodne tech 8K? To nejak souvisi s velikosti 1B = 8b tak nejakej nasobek nebo co? Jeste jsem se nesetkal, ze by se nekde u tak velkyho projektu jakym bezesporu Lin jadro je resilo ze se neco omezi. Praxe je vetsinou opacna, nedostatecne se neco nadimenzuje a pak se hleda zpusob jak to rozsirit.

[Luk]

Tipuji, že to bylo výsledkem pozorování a pokusů, kolik paměti je v praxi pro zásobník potřeba (podobné hodnoty se totiž vyskytují i u jiných systémů - mám pocit, že u Windows to také bývalo 8 KB, ale pak to zvětšili na 12 KB).

[Miloslav Ponkrác]

Windows garantuje pro kernel mód 12 KB zásobník pro thread a 32/64 KB zásobník pro GUI thread. Windows vnitřně rozlišuje thready na "lehkotonážní" a GUI (to jsou ty, které nějakým způsobem využívají uživatelské rozhraní). Kernel ve Windows automaticky bez jakéhokoli zásahu programátora zkonvertuje "lehkotonážní" thread na GUI při volání první funkce API GUI rozhraní.

Jinak ve Windows se dá zásobník zvětšit, například ve Vistách je v kernelu volání KeExpandKernelStackAndCallout.

Osobně si myslím, že 4 KB v Linux kernelu není šťastné řešení, a že by tam měla být minimálně možnost ho zvětšit na požádání.

[xm]

Proč si myslíte že 4 KB není šťastné řešení? Já vidím jen samé klady a pozitiva. Linux funguje jinak než Windows.

[Luk]

U některých ovladačů by to opravdu mohlo dělat problémy (i když je samozřejmě prakticky vždy lepší to dát do pořádku). Tím spíš, že cesty, kterými se běh ubírá, jsou někdy dost nepředvídatelné - volání může jít přes celou kaskádu modulů, přičemž nelze predikovat, jak dlouhý ten řetězec bude.

[xm]

Ano, vím že to kdysi dělalo problémy třeba reiserfs. Ale to je problém blbě napsaných ovladačů, který by měl být opraven, nikoliv problém 4K stacku.

[Jirka P]

Největší problém 4K stacku je, že nikdo neví, jestli to funguje. Chtělo by to nějaký funkční detektor přetečení.

[Miloslav Ponkrác]

Proč si myslíte že 4 KB není šťastné řešení? Já vidím jen samé klady a pozitiva. Linux funguje jinak než Windows.

Já zase ta pozitiva až tolik nevidím. Například 64 bitový pointer v 64 bit módu zabere 2x tolik místa na stacku, než 32 bitový pointer.

A vzhledem k tomu, že Linux nijak nedetekuje a nedá programu najevo, že pozor, teď se blížíš hranici vyčerpání zásobníku jak to dělají Windows, tak je to vlastně taková malá sw bezpečnostní díra jak shodit Linux přímo v kernelu.

Navíc si myslím, že složitější drivery opravdu pár kilo na zásobníku potřebují. A měly by mít možnost dostat trochu víc, než je 4 KB, to je na 64 bitový mód opravdu málo. Určitě je to lepší, než když jako programátor budu psát:

static char muj_vlastni_zasobnik[64 * 1024];

.... nastav_registr_xsp_na_konec_pole_muj_vlastni_zasobnik(); ....

Protože s touto 4 KB strategií se také mohou velmi rychle v kernelu dostat na to, že v modulech se budou vyskytovat interní globální pole, které si přehodím na zásobníky, abych měl na něm trochu více prostoru - a ve výsledku to povede k menší efektivitě kernelu i jeho větší spotřebě paměti.

[Miloslav Ponkrác]

Proč si myslíte že 4 KB není šťastné řešení? Já vidím jen samé klady a pozitiva. Linux funguje jinak než Windows.

Možná bych pro pochopení měl ještě napsat, že dvojková soustava, strojový kód i další věci opravdu překvapivě fungují stejně pro Windows i pro Linux. Dokonce i režie zásobníku při práci s kernelovými věcmi je zhruba plus mínus stejná. Je sice hezké se v tomto nadřazovat na Windows, nicméně tady není proč - režie volání podprogramů je stejná pro Linux i pro Windows, režie parametrů na zásobníku je také stejná u Linuxu i u Windows. Mohl by mi autor vysvětlit, co myslí (pro tento konrétní případ - tedy hodnocení, jestli 4 KB stacku stačí či nikoliv), kde je ten výrazný rozdíl mezi Linuxem a Windows?

[Luk]

Windows garantuje pro kernel mód 12 KB zásobník pro thread a 32/64 KB zásobník pro GUI thread. Windows vnitřně rozlišuje thready na "lehkotonážní" a GUI (to jsou ty, které nějakým způsobem využívají uživatelské rozhraní). Kernel ve Windows automaticky bez jakéhokoli zásahu programátora zkonvertuje "lehkotonážní" thread na GUI při volání první funkce API GUI rozhraní.

Jinak ve Windows se dá zásobník zvětšit, například ve Vistách je v kernelu volání KeExpandKernelStackAndCallout.

Díky za informaci, měl jsem o tom jen velmi matné povědomí.

Osobně si myslím, že 4 KB v Linux kernelu není šťastné řešení, a že by tam měla být minimálně možnost ho zvětšit na požádání.

Možnost zvětšit zásobník by tam určitě měla být. Tím spíš, že by nešlo o velký zásah do implementace (klidně by se tato možnost - stejně jako se dnes zapíná 4K zásobník - mohla zakompilovávat jen volitelně).

[Jirka P]

Tím spíš, že by nešlo o velký zásah do implementace (klidně by se tato možnost - stejně jako se dnes zapíná 4K zásobník - mohla zakompilovávat jen volitelně).

Zakompilovávat volitelně by to šlo, ale zásah do implementace by to určitě byl - teď jádro předpokládá stejnou (a konstantní) velikost zásobníku u všech vláken (a například Miroslavem Ponkrácem uváděný hack s globálním polem je nekorektní).

[Luk]

zásah do implementace by to určitě byl - teď jádro předpokládá stejnou (a konstantní) velikost zásobníku u všech vláken

On by ten zásah (z hlediska provedených změn) nebyl až tak drastický. Větším problémem by ale byla analýza, kterou by bylo potřeba provést, aby se podchytilo vše, na co by měl nastavitelný zásobník dopady.

například Miroslavem Ponkrácem uváděný hack s globálním polem je nekorektní

To by byla především obrovská prasárna a nedokážu si představit, že by nějaký takový modul prošel do hlavního stromu.

[Miloslav Ponkrác]

To by byla především obrovská prasárna a nedokážu si představit, že by nějaký takový modul prošel do hlavního stromu.

Prasárna to je, ale nicméně je možné, že Linux do podobných prasáren pár autorů složitějších modulů donutí. 4 KB zásobník je dost málo a dokážu si představit nějaký sofistikovanější driver - třeba složitého filesystému, nebo složitého hw, že 4 KB překročí. Pak bych jako autor prostě dynamicky jádro požádal na každý thread o potřebný blok paměti a hodil bych zásobník na konec bloku paměti, protože jiné solidní řešení je jenom horší.

Kromě toho znovu píšu, Linux nemá solidní možnost jak zjistit, že zásobník přetéká. Ve Windows toto hlídání je řešeno výjimkami v jádře - tudíž nestojí žádný čas, ani rychlost a efektivita kernelu se nesnižuje. Pokud to budu chtít realizovat v linux kernelu se 4KB stránkou na zásobníku, pak musím uměle vkládat kontroly a snižuji rychlost a efektivitu běžícího kódu.

Miloslav Ponkrác

[Luk]

4 KB zásobník je dost málo a dokážu si představit nějaký sofistikovanější driver - třeba složitého filesystému, nebo složitého hw, že 4 KB překročí.

Jenže on je ten prostor 4 KB vyhrazen celý pro zásobník vlákna v jádře (kromě krátkého thread_info na začátku). Hardwarová a softwarová přerušení mají vlastní zásobníky. Nepřipadá mi to o tolik horší než starý model, kde bylo min. 1,5 KB užráno prostřednictvím task_struct a přerušení se obsluhovala na témže zásobníku.