Názory k článku Nový plánovač jádra nabízí rychlejší reakce

Občas se mi stává, že při nějaké náročnější operaci (načítání velkého obrázku, kopírování mnoha souborů...) se celý systém na chvíli zasekne. Moc mě to nevadí, ale přijde mi to záhadné. Priority jsou stejné (nice=0) a linux by měl umět čas procesoru rozdělit mezi všechny procesy i při 100% vytížení.

Linuxový scheduler se snaží "uhodnout", které procesy jsou interaktivní a které ne a pokud to uhodne blbě a usoudí, že ten proces, co kopíruje soubory, je interaktivní, tak ho začne upřednostňovat před ostatními.

V některých starých 2.6 jádrech se díky bugu v tomhle dal i celý systém vytuhnout trvale.

hmm ten seminar uz je plnej, jak to teda je kdyz vlastnikm je Windriver...
Neni nekde srovnani hard real time systemu (rtlinux, qnx, vxworks, ardence, ...)?

btw myslite ze to co je citovano vyse zvladne i DOS pokud jde o nejakou trivialitu a neni nutne planovat nebo je nutne "planovat" vzdy - odlozit interupty na pozdeji?

No, BLEKu, a jak mas udelanej scheduler ve SPADu?

Stromovej --- procesy tvoří strom, scheduler postupuje od kořene, a na každé úrovni přiřazuje čas spravedlivě. Má to výhodu, že když nějaký program udělá while (1) fork(), tak nezpomalí ostatní procesy.

Otazka zni, jestli je to tak dobre. Tj. jestli je vysledek lepsi.

U kopirovani se muze zasekavat ne kvuli zatezi procesoru, ale kvuli zatezi sbernice. Nevim, jak hodne soucasne planovace pocitaji se zatezi tohoto uzkeho hrdla, ale asi moc ne, zejmena kvuli DMA, kdy procesor do samotneho procesu nema co kecat.

"...kdy procesor do samotneho procesu _kopirovani_ nema co kecat."

Sorry za nejasnost.

jj to poznam. napr pri zasuvani a vysuvani optickej mechaniky to zasere celu zbernicu. SATA disky idu v pohode, ale PATA disk (ktory je na tom istom kabli ako DVD) nie. Ja by som ten disk aj dal na druhy kabel, ale mam len jeden radic. a zase kupovat nejaku kartu len kvoli tomu je zbytocne :)

Vysledoval jsem ze tohle zalezi na mechanice. Nektery mechaniky to delaji a nektery ne.

V jádře funguje kooperativní rozdělování procesorového času. Když kopírovací proces rozhodne že žezlo dál nepředá, tak se systém začne cukat.

tak to snad bolo vo windows 3.x, nie?

Userspace je preemptivni ale s kernelspace je to mnohem slozitejsi. I s CONFIG_PREEMPT na to vubec nelze spolehat. To je duvod, proc jadro nesmi vyvijet cyklisti!

ahaa, i/o scheduler :o)) tak nic, o tom az tak vela neviem :-)

Mam uplne stejne problemy. Pri praci to nijak zasadne nevadi ale pokud napriklad otevru novou zalozku v FF, nacita se stranka, minimalizuji Eclipse nebo startuje nejaky program (jen nektery asi narocnejsi.) Zacne pocukavat myska nebo odlozeni docela trva a nasledne prekresleni je pomalejsi nez by melo byt. Nejsem puntickar ale trochu me tahle prkotina mrzi.

A nezkousel jsi davat nizsi CONFIG_HZ?

Jednu dobu jsem to taky zkoušel s 1000Hz no odezva při nezatíženém systému perfektní. Ale jak se začlo kopírovat nebo dělat cokoliv jiného tak ani se snížením priority jsem moc nezmohl, překreslení okna tak minuta, dvě. Doporučuji snížit tu frekvenci na 300 nebo 200Hz

Zdravím,

chci se zeptat jaká konkrétní rizika můžou hrozit když se tohle nasadí na produkčním stroji?

díky

Je zde zvysene riziko prenosu pohlavnich chorob - planovac naplanuje ulohy efektivneji, drive se vykonaji a zbyly cas muzes vyuzit na sex.

To u mně nehrozí --- já mám poruchu osobnosti, tak sex neprovozuji.

Spis jses neurotik. Opravdovi psychopati svoji poruchu neresi a vetsinou si ji ani neuvedomuji

On nepsal, ze je psychopat... existuji ruzne typy poruch osobnosti a krome toho existuji ruzne typy osobnosti obecne...

Já jsem si svou poruchu taky neuvědomoval, dokud jsem nezačal chodit na psychoterapii. Začínal jsem si ji pomalu uvědomovat až po roce psychoterapie.

pokud nemá nastavený promisc režim, tak bych se toho nebál.

Aha, díky za vyčerpávající vysvětlení ;)

Takže to mám chápat jako že nemá -žádná rizika- a nebo RTFM?

Radsi RTFM v clanku pisi "neotestovany a neodladeny kod", tak bud rozumnej ;-)

Ahoj,

Pokud mám procesy, které namísto CPU vytěžují HD,
existuje také nějaký plánovač pro disky?

+ plánovač sítě s nastavitelnými prioritami

Ano, v jadru je vyber z nekolika planovacu (anticipatory, deadline, CFQ...) a daji se menit i za behu zapisem do /sys/block/_zarizeni_/queue/scheduler

Priority viz http://www.die.net/doc/linux/man/man1/ionice.1.html

Je to jeho vlastni algoritmus, nebo byl uz publikovan nekdy predtim? Protoze jestli je to jeho algoritmus, posunul operacni systemy obecne o dost dal. A ze to bylo zrovna v Linuxu, to je skvele.

Tento chlapik zije s planovacmi uz niekolko rokov.

Teoreticke principy akychkolvek pouzivanych planovacov su zrejme dobre opisane uz aspon 50 rokov. Lenze "akademicke" definicie planovacov su velmi zjednodusene a jednostranne.

V nedavnom rozhovore Ingo vysvetloval, ze navrhnut dobry planovac je omnoho tazsie nez "vymysliet" nejaky "zarucene dobry system". Planovace dneska sice vyuzivaju zname postupy, ale vacsinou kombinuju niekolko hladisk a niekolko principov naraz, a najviac zalezi na celkovom vyvazeni, aby sa co najviac prejavili kladne stranky jednotlivych algoritmov, a co najviac potlacili ich negativne stranky. Tu a tam sa pouzije nejaka pomocka alebo "tuning".

Preto je skor dolezite sledovat, ako sa ktory planovac sprava v skutocnej zatazi, a "tu a tam pritiahnut skrutku". Skratka ladit. Clovek, ktory toto robi, musi mat velke skusenosti, dlhodobo vypestovany "sluch" pre odozvy systemu. Az potom ma predstavu, ako sa ma vlastne planovac spravat v REALNOM systeme.

Aj preto Ingo vytvoril patch, ktory umoznuje menit nielen parametre planovaca, ale dokonca planovac samotny, za behu systemu! Iba takto sa totiz da porovnavat ich spravanie v realnej prevadzke. Bez rebootovania.

Planovace se daji menit za behu uz pradavno ( viz napr. man sched_setscheduler, http://ccrma.stanford.edu/planetccrma/man/man2/sched_setscheduler.2.html )
Parametry planovacu se daj menit za behu uz pradavno (/proc/...), jen soucasny O(1) ma tolik parametru ze v podstate nikdo nevi co jak a proc nastavit.

Jestli jsou 50 let teor. popsane planovace bez timeslicingu si nejsem jisty (ale naprosto to nevylucuji) - muzes uvest nejaky odkaz nebo zdroj?

Se zmenou planovace za behu jsem asi kecal, omlouvam se - menit se da pouze scheduling policy nejakeho procesu, ale ne scheduler samotny. Pardon.

Trosku jsem se tesil (i kdyz jsem v to moc nedoufal), ze se dozvim predevsim vysvetleni a technicke zajimavosti toho, jak planovac funguje (priznavam na jednom radku to tu je popsane a na nekolika dalsich jsou uvedeny dusledky), a ne tolik bulvaru okolo, tedy jak dlouho trval vyvoj a ze willy to zkousel a zda se mu to byt dobre.

Tim nechci mit nic za zle willymu, myslim ze Willy Tarrerau planovacum rozumi, ale lide kteri to jmeno nikdy neslyseli mohou chapat clanek jako "jo, aspon ze to nekdo vyzkousel".

Asi by take nebylo od cesty uvest, ze Con Kolivas je v podstate otcem cele myslenky CFS a na svem Staircase Deadline CPU scheduler, z jehoz zkusenosti CFS velmi silne vychazi, pracuje intenzivne jiz nekolik let. Podle informaci na www (napr. hned prvni odkaz clanku, http://kerneltrap.org/node/8059 - _velmi_ zajimave cteni) ma na CFS vetsi zasluhy nez Ingo Molnar. Cesta byla Conem objevena jiz davno - ale az ted se o ni zacina mluvit.

A ne, nechci napsat na root vlastni a lepsi clanek :)

Taky bych uvital detailnejsi technicky popis toho planovace.

RSDL je popsan v Jadernych novinach. CFS asi jen na kerneltrapu.

co ty teda vlastne chces kluku?!

V dusledku je to vzdycky a jenom sex. Freuda jsi necetl co?

Freud přeháněl.

Feud sex podcenil.

A jaky planovac ma Windows XP?

Vzhledem k pohotovému a ojedinělému OS, jakým Windows bezesporu jsou, je obecně známo, že plánovač v tomto OS je nejlepším v celé množině OS na světě.
Již několik let se zabývám zkoumáním plánovače na systémech Windows. Například dokážu již dnes naplánovat, aby se mi vypnul počítač po dvou hodinách. Dokážu si naplánovat, aby se mi spustil spořič obrazovky a umím si naplánovat pravidelnou kontrolu mailů.
Jak vidíte jsem opravdu dobrý programátor - nemluvě o hackování panelů již jak ve Windows tak i v GNOME a zvládnu už konečne po roce usilovné práce i KDE.
Já jako nelepší OS považuji GNOME, protože linux stojí za prd a windows taky.
Ale zpět k vašemu dotazu. Windows má jedinečný plánovač - nenajdete ho v žádném jiném OS, přestože se jedná o sprostou kopii Mac OS X.
Ten plánovač se jmenuje Blue Screen a je opravdu obtížné jej hacknout, protože se jedná o jakýsi typ viru, který dokonale maskuje svoji činnost. Několik dní jsem odolával útokům viru Blue Screen a stejně se mi jej nepodařilo vymítit. Domnívám se, že tento vir je spouštěn právě oním plánovačem, ale ten asi používá díky analýze lidského faktoru jisté prvky umělé inteligence a pravděpodobnosti. Můžu však s přesností 100%, že plánovač spustí Blue Screen právě v okamžiku, kdy vás to nejvíce nasere.
Proto doporučuji nepoužívat produkty MS. Nikdy nevíte, jaký nový vir vám dodají.
Kdyby jste potřeboval hacknout GNOME panel, pomůžu velice rád.

Soulasím:-)

Na http://www.academicresourcecenter.net/ je mozne najit ProjectOZ. Tam je mozne si na "pomerne jednoduchem" OS vyzkouset, jak to cele funguje. Kernel ktery tam je funguje jako ten ve WinXP (nevidel jsem kod WinXP, takze nevim nakolik je to pravda).

Mno, pokud mě paměť neklame, ve Windows NT (2000, XP, ...) je použito preemptivní plánování "shortest job first" s předbíháním. Někdy bývá také označován jako Shortest-Remaining-Task-First. _Velmi_ zjednodušený popis některých plánovacích algoritmů najdete zde: http://www.fi.muni.cz/usr/staudek/vyuka/opsys/07_planovani.pdf

Zajímalo by mě jedno - jak je možné u interaktivních procesů, démonů apod. určit "shortest remaining task"? Není tohle teorie jakž takž platná v době sálovývh počítačů a výpočetních středisek?

Proctete si material na vyse zminenem odkazu, konkretne stranu 14 a uz vam to bude jasne :-)

ten pracuje na principu nedefinovatelných náhodných stavů.:-)

Tady na rootu pred lety nekdo psal porovnani novinek z FreeBSD a Linuxu a byly tam vysvetleny dost low-level veci. Bylo to vice clanku, tak se zkus mrknout: http://www.root.cz/serialy/porovnani-systemu-linux-a-freebsd/
Bylo tam porovnani s widlackym zpracovanim ICQ, planovac nevim. Kazdopadne pekne cteni.

Tento chlapik poslednu dobu "ladi" novy SMP scheduler vo FreeBSD:
http://jeffr-tech.livejournal.com/
a publikoval aj nejake testy s Linuxom (problemy so skalovatelnostou):
http://people.freebsd.org/~jeff/sysbench.png

Dufam, ze jeho praca pomoze obom systemom stat sa este lepsimi.

Jak tu nekdo zminoval, jde o SRTF, ktery je pro desktop daleko lepsi nez firstcome scheduler linuxu. Zajimalo by me jak se jednotlive schedulery projevuji v multiprocesorovem prostredi.
Mr. Murzim: nechcete jit prispivat na stranky zive? Tam byste byl mezi svými.

... se v Česku vyučují na VŠ. Proč je nazýváte rbtree?

rbtree je standartny nazov pre algoritmus. Ako VS v CR vyucucju (nazyvaju) napr "double linked list" alebo "bubblesort" ;)

double linked list = obousmerny (zretezeny) seznam
buble sort = razeni probublavanim, bublinkove razeni ci razeni zamenou
Jeste neco chcete prelozit?

prave preto sa vacsinou pouzivaju anglicke nazvy, lebo to je terminologia...
bubblesort si prelozil 3 roznymi nazvami...je to prehladnejsie?

Ale kazdemu z tech tri jde rozumet.

Treba je to nahoda, ale uz drive jsem si vsiml, ze slovaci jsou mnohem nachylnejsi k przneni sveho materskeho jazyka nez cesi.

pretoze rbtree rozumie kazdy, ale Cerveno-cierne stromy, to je nieco co musim hodit do googla, aby som zistil, ze tym vlastne myslel autor zmienovane rbtree

A ještě lampo z VŠ, pokud to chceš překládat, tak to musíš vzít opisem. "Červená a černá" má v anglosaských (možná frankofonních) zemích ten význam jako u náš "černá a bílá" (tj. "opačné barvy").

na stranke http://kernel.jakem.net/ sa da najst patch na uz existujuce scheduleri, ktore vie vytunovat podla pouzitia systemu. samotny scheduler sa nemeni, menia sa len jeho nastavenia v zavislosti od toho, co na systeme bezi.

Napadá mě otážečka. Proč neudělat procesové plánovače nastavitelné, jako je tomu například s vv plánovači. Jistě že to zní trochu podivně, ale zas by to mohlo být zajímavé. Mít možnost měnit za běhu plánovač procesů zní velmi lákavě, obzvláště, když se tu vynořily další dva.

Osobne me velmi prekvapila odezva a celkove velmi vyrovnany vykon MacOS X. Nevite nekdo detaily, proc tomu tak je - zaslechl jsem cosi o velmi dobre napsanych low-level ovladacich atp. Nebo je to prave planovacem?

Rekl bych, ze tam maji prepinani uloh po velmi malych kvantech, protoze "hruby" vykon neni nijak oslnivy, ale celkova odezva systemu je vyborna (napr. na 3 roky starem G5 se mi nikdy nezadrhla prehravana mp3 - ani pod jakoukoliv zatezi, coz se bohuzel u Linuxu obcas stane, u Win nevim).

Vite o tom nekdo neco?

P.S. pro majitele Macu doporucuji v terminalu prikaz latency - moc zajimave :)
Napr. u me ted:
minimum latency(usecs) 4 0
maximum latency(usecs) 56281 139
average latency(usecs) 54 1
exceeded threshold 0 0

To muze ale byt i tim, ze na Macu jadro muze znat mnohem lepe aplikace a knihovny, ktere jsou dodavany se systemem a podle toho se k nim chovat.

Problém odezvy Linuxu je v nepreemptivním kernelu (po dobu běhu kernelu se provádí context switch jen na pár místech; CONFIG_PREEMPT mají distra vypnutý, protože dělá problémy). Navíc Linux neumí pracovat s prioritou IRQ, na rozdíl od NT. MacOS se prostě chová jako běžný systém (třeba NT). Zadrhávání MP3 je věcí popsaných konceptů, plus velikosti bufferu.

Zásadním problémem MacOS je použití mikrokernelu, díky kterému jde do kytek výkon threadů. Proto mají NT modifikovaný mikrokernel (se servery v kernel mode).

Používám Fedoru 6. Pokud zapnu AIGLX efekty začne obraz při zátěži trhat, zasekávat se. Přitom graf. karta je určitě dostatečná. Nepomohlo by nějaké lepší nastavení plánovače nebo priority nějáké služby?