Jak zlepšit plánovač bez 200řádkového patche

Před několika dny vyšla zprávička o dvousetřádkovém patchi, který zásadně zlepšuje odezvu systému při vysoké zátěži. Mezitím se objevilo řešení, jak se dá toho samého dosáhnout bez aplikování patche. Není to však hezké řešení, takže patch by se měl do jádra dostat tak či tak.

19.11.2010 13:28 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[WEITS]

Vyuzil jsem alternativu pro Kubuntu a subjektivne se mi system jevi mnohem sviznejsi. Asi to fakt funguje.

[sivlk]

Imho je to len tvoj pocit

[mektige]

To by mě zajímalo, jestli to funguje i když mám jako default shell (/bin/sh) dash místo bashe.

[karrol]

Takže jsem zaktivoval dle návodu cgroups - vše funguje, procesy se přidávají do /dev/cgroup/cpu/user/ jak mají, ale žádné zrychlení nepozoruji, například glxgears dávají stejnou hodnotu jako normálně, ale při zátěži dávají výsledek dokonce horší. Přesouvání oken se při zátěži systému trhá spíše více než předtím. Asi bude nějaký rozumný důvod, proč tato volba není jako výchozí aktivována.

Jsem zvědavý, zda 200lines patch - který údajně funguje poněkud jinak - bude úspěšnější...

[chrono]

A čo konkrétne si okrem glxgears púšťal?

[Jiří J.]

Jak jsem už psal v původním vlákně, pozorní čtenáři toho LKML threadu mohli na Lennartovo řešení natrefit už tehdy. Jak se tam ale také upozorňuje (a jak jsem psal i já) - na běžném desktopu neběží aplikace běžně přes TTY. Ano, pro kompilaci kernelu to funguje, pro aplikace puštěné z konzole s vlastním terminálem to taky funguje, ale to je tak všechno. Pokud aplikaci pustíte třeba z KDE/Gnome panelu, spadnou do stejné skupiny.

V té diskuzi padl i nápad zdokonalení podpory cgroups v systemd, který by tak mohl házet alespoň daemony do skupin zvlášť, nicméně i tak by zbývalo vyřešit ještě ostatní aplikace. Jak už naznačili ostatní - prosté přidání pár příkazů před spuštěním binárky nestačí, něco musí sledovat skončení dané aplikace a odstranit group. A mít pro každou větší aplikaci vlastní wrapper? Ne, díky.

Kernelovské řešení není v současnosti o moc lepší, ale jsou tam snahy o další možnosti heuristiky a detekce. A také větší potenciál.

Mě ososbně se líbí Linusova vize - cgroups jako subsystém s kernel config možností automatického přidělování procesů do skupin na základě použití různých (rozšířitelných, vylepšitelných) metod heuristiky. Nezávisle na userspace wrapperech. Nezávisle na distribuci. Transparentní odebrání skupiny po skončení procesu/procesů.

[Jiří J.]

Tím chci naznačit, že ani ten kousek .bashrc skriptu, ani současný 200line kernel patch nedělá prakticky NIC pro běžného Ubuntu usera. Ten by musel všechny větší aplikace pouštět přes wrappery nebo z terminálu.

[karrol]

V tom "rozšířeném" návodu je ošetřeno i zrušení skupiny po zavření terminálu, jestli tomu správně rozumím.

Zkoušel jsem aplikace spouštět každou ve svém terminálu (v dev se objevilo nové číslo pro každý z nich), ale stejně jsem žádné oživení nepozoroval...

ne, že bych byl překvapený, na to jsem už dost starý, jen se podivuji, jaké skvělé zlepšení reportují uživatelé na fórech. Že by opravdu ten profláknutý placido effect?

[moo]

placebo

[karrol]

ftip

[Jiří J.]

Ono je to tím, že cgroups nejsou všelékem. Plánovač sám o sobě není špatný, CFS jako "fair" scheduler opravdu dělá svoji práci, pokud se jedná o jednoduché schéma několika procesů. Pokud pustíte třeba firefox a thunderbird a v obou se vám povede "vytížit CPU na 100%", pak (na uniprocessor systému) dostane každý proces přibližně 50%, na střídačku.

Problém je, že věci jako make spawnují pro každý zdrojový soubor novou instanci GCC. Myslel jsem, že by se o to měl postarat nějaký kód, který by teoreticky mohl počítat cputime potomků do celkového cputime rodiče, ale asi to tak nefunguje a plánovač bere každé nové spuštění gcc jako samostatný proces, který má plný nárok na processor.

[karrol]

Aha, takže efekt by se měl projevit např u kompilace, kde by se pak měla zlepšit odezva ostatních běžících aplikací? Zkoušel jsem to opravdu jen na několika současně spuštěných aplikacích (chron: mimo ty zmíněné glxgears to byla mozilla, nějaké to video a pár terminálů), jako model nějakého běžného desktopu. Tam se grupování neprojevilo nijak pozitivně. Je tedy rozumný závěr, že pokud nehodlám na počítači dělat jednu kompilaci za druhou, tak z této změny prospěch není? Ví někdo, jestli by to zvýšilo propustnost Apache nebo podobně?

[stativ]

Podle mě by mohlo být zajímavé, kdyby cgroups používal xserver.

[trekker.dk]

Není to však hezké řešení, takže patch by se měl do jádra dostat tak či tak.

Vcelku důležitá oprava: Linus si myslí, že...

Bohužel jak Lennart podle mě vcelku trefně podotknul (a jak se píše i v #5), většina uživatelů nepoužívá počítač stejně jako Linus a pár dalších vývojářů jádra, takže u nich patch nebude fungovat.

Článek o tom bude v JN; když jsem ho překládal, tak se mi zdálo, že Linusovi už asi trošičku hráblo...