Malá úprava plánovače CPU výrazně zlepšuje odezvu systému

Phoronix informuje o dvousetřádkové úpravě Linux kernelu, která velmi výrazně zlepšuje odezvu systému při vysoké zátěži. Tento patch, který se Linusovi velice zamlouvá, by měl být součástí Linuxu od verze 2.6.38.

16.11.2010 17:11 | David Watzke | Zajímavý článek

Komentáře

[Tom]

Konečně dostane možnost i moje 486, která čeká na svůj novodobý vrchol ve kterém porazí současný Athlon64 6000+

[mikirc]

a v cem ? v hrani tetrisu? :D

[Tom]

Nene, v hraní min

[Xerces]

To není vůbec o optimalizaci výkonu. 486 bude pořád stejně pomalá spíš o optimaliazci plánování (opravdu plynulé ikdyž třeba při velké zátěži pomalé scrollování, atd.). Tak jsem to pochopil já. Každopádně jsem na to zvědav. Zdá se že hrátky se schedulery konečně pro desktop přinesou ovoce.

[Petr]

No ale pro 486 je cokoliv "velká zátěž", takže je to vlasně pro ni jak dělaný

[Tomáš]

Nevím, 486 tohle nepotřebuje. Když jsem jí měl, tak jsem současně přehrával nějaký MP3, graboval CD do jiných MP3, kompiloval kernel a serfoval po internetu přes modem a procházení netu bylo plynulé a přehrávání písniček se taky necukalo. Je fakt, že to byla ta lepší 486, AMD486/133MHz.

Takže pro nějakou na 25MHz by to asi mohlo být potřeba

Ale abych byl objektivní, vše jsem tedy dělal v textovém rozhraní.

[omg]

dx2 66MHz ... mp3 v textu a tim to konci. a to jeste nesmel byt zvuk jako modul, ale built in. jako modul to davalo akorat 22kHz mono. S built in podporou zvuku v kerenelu to umelo stereo 44kHz.

[MMMMMMMMM]

Těším se na ten nový kernel.

[D.A.Tiger]

+1

[pepe_]

Už před 5 lety bylo pozdě ...

[JanM]

a pokud to někdo nebackportuje (fuj, to je ale slovo), tak si většina uživatelů ještě chvíli počká...

[knizmi]

Off topic
O kradení nicků už jsem slyšel, ale o kradení jmen?!!!
Ale vážně - díky tvé stránce o tvé existenci vím, ale netušil jsem, že jsi registrovaný i zde

[JanM]

Ještě dodám, že s nickem MilanK (bez přihlášení) se tu občas objevuje i Milan Keršláger (tedy alespoň si to myslím).

[Marián Kyral]

Bohužel, teď jsem to zkoušel a na 2.6.36 to aplikovat nejde Takže buď to někdo dostane do 2.6.37 nebo bude třeba počkat až na .38.

[AsciiWolf]

+1

[jehovista]

chci, chci, chci!

Hadam ale, ze umrtveni desktopu pri kopirovani velkeho mnozstvi dat to neodstrani.

[kralyk z abclinuxu]

Jo, to se totiž odstraňuje nečím jiným, už nevím čím, někde to tu bylo v diskusi...

[jehovista]

Doufam, ze tou radou neni vymena OS.

[kralyk z abclinuxu]

Ne ne, bylo to něco s I/O (nečekaně ), nevim přesně, třeba někdo povolanější poradí...

[jehovista]

Nemyslis tuhle diskuzi, ktera je pomerne ziva uz rok a pul? Procital jsem to naposledy tak pred pul rokem, ale na funkcnim reseni se neshodli

[Delaunay]

To je již uzavřené téma. Pro pokračování diskuze viz http://forum.root.cz/index.php?topic=770. Po upgradu na 2.6.36 se latence při enormním I/O zatížení o jeden až dva řády zlepšila. Tedy alespoň na mém stroji .

[belisarivs]

To tezko.

Kopirovani ~2,5 GB dat ve Windows 2003 server ten system slozilo jeste drsneji. V Linuxu dojde ke zpomaleni. Ale Widle byly uplne hotove, kdyz jsem to neumyslne vyzkousel.

[jehovista]

Ac jsem zaryty linuxak, tak za sebe mohu prohlasit, ze mam mnohem lepsi subjektivni pocit pri presouvani velkeho mnozstvi dat ve windows.

[kralyk z abclinuxu]

+1 :-/
No snad se to s .36 zlepší, jak prorokováno výše...

[belisarivs]

Nevim. testoval jsem Linux nad Hyper-V.

Dal jsem stahnout ~2,5 GB instalacni image Linuxu pres IE (na masine nebyl zadny jiny browser) v tech Win (nevim, jestli to byly 2003 nebo 2008, uz si nevzpominam), ktery je tak blby, ze taha data nekde do tempu a az pak je presune na spravne misto. A v ten moment presunu byla ta masina lautr nepouzitelna. To jsem jeste nikdy nezazil.

[hugo]

to neni bug, to je featura. tenhle problem souvisi s tim, ze matlaci z MS vymysleli genialni reseni, ze IE si stahne data do interniho tempu a pak po stazeni je zkopiruje (pouzije copy, ne move) a na zaver odmazne z toho tempu. a to kopirovani je vetsinou v ramci jednoho disku, takze tim ten disk usmazi, nasledne zatuhne pocitac a uzivatel kolabuje... no, jinak, ve FF ci jinem slusnem prohlizeci se to nestane, takze IE holt nebrat a nepouzivat ;)

[Delaunay]

Musím potvrdit, opravdu jde o vlastnost. Kopírování se děje proto, aby se na pozadí mohla provádět kontrola obsahu. Provádí se pro ZIP soubory a ISO obrazy linuxových distribucí. V obou případech se zjišťují porušení autorských a patentových práv Microsoftu a informace o nich se zabezpečeným kanálem odesílají do data mining centra a právnímu oddělení k zevrubnější analýze.

Pouze kontrola ZIP souborů se dá vypnout zásahem do registru. Stačí ve větvi HKEY_CLASSES_ROOT\CLSID odmazat klíče {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31} a {0CD7A5C0-9F37-11CE-AE65-08002B2E1262}.

A pro jistotu ještě smajlíka

[omg]

priorita programu na popredi nebo na pozadi?

[kralyk z abclinuxu]

Kdo je autorem patche? Ten "Mike Galbraith"? Nebo.... Neříkejtemi, že Phoronix

[David Watzke]

Mike, samozřejmě - Phoronix těžko

[David Watzke]

Nahlídnul jsem do toho patche, jen abych to prolít a tohle mě tam praštilo...

+	if (ag) {
+		kfree(ag);
+		WARN_ON(1);
+	} else
+		WARN_ON(1);

[Karry]

když se podíváš do mailing listu, tak takových výtek je požehnaně... to ale u takovýchto šíleností které vznikaly pokus/omyl je celkem normální...

[jehovista]

aneb kdyz milion opic zasedne k psacim strojum...

[Jiří J.]

Tak nejsem sám

[Karry]

# uname -r
2.6.37-rc2
# cat /proc/sys/kernel/sched_autogroup_enabled 
1
# uptime 
 00:13:02 up 14 min ...

Zatím jsem akorát zjistil jak spolehlivě tohle jádro shodit :)

# echo 1 > /proc/sys/kernel/sched_autogroup_enabled 
# cat /proc/sched_debug 

[D.A.Tiger]

Vypadá to, že se vývojáři změřili na optimalizování kernelu na desktopy. Nebylo by možné napsat nějaký článek přímo o tom? Tedy mám na mysli nějaký souhrn těchto úprav a popř možnosti konfigurace...

[kozzi]

Ehm zrovna tento patch se moc na dekstopy nevztahuje. Teda minimalne pro vetsinu uzivatelu to nebude zadna zmena

[D.A.Tiger]

Ehm, máš pravdu, je tam napsaný "při vysoké zátěži". Hmmm... jdu zpět do třetí třídy naučit se číst

[Selmi]

ale bude. nanestastie pre desktop je vysoka zataz uz ked kliknes vo firefoxe na skupinovy bookmark ktory ti naraz otvori cca 30 tabov ktore sa vsetky zacnu nacitavat... do toho spustis nieco na maily, rhytmbox...nie je to dlhodobe ale je to tam

[michich]

Který z těchto procesů má vlastní tty? Nejspíš ani jeden z nich, takže ten patch se v takové situaci nejspíš neprojeví.

A to, že Firefox je při otevírání mnoha tabů dočasně nepoužitelný, je problém Firefoxu samotného, kterému scheduler nemůže pomoci.

[michich]

Který z těchto procesů má vlastní tty?

Napadlo mě, že Xorg asi jo. Ten tedy s tím patchem dostane o něco více času CPU.

[Jiří J.]

Dostane, ale kam se poděje ten zbytek? Na daemony, kteří berou sotva 0.1% CPU time? Důkladně jsem procházel vlánka na LKML a pravdou je, že TTY jako jediná heuristika určitě nebude "běžnému desktopu" stačit. Padl tam (opět) nápad dělat tohle z userspace, což jde i teď bez patche. S trochou vlastních skriptů a wrapperů by se mohlo podařit izolovat klíčové aplikace do svých group. Nicméně předpokládám, že se patch do kernelu i tak dostane a časem přibydou jiné metody heuristiky, ač se nezdá, že by Linusovi vadil současný stav, kde mu make -j64 jede plynule .