CFS backportováno a bude snad v Linuxu 2.6.24

Completely Fair Scheduler byl pro velký zájem backportován na Linux 2.6.23-rc8, 2.6.22.8, 2.6.21.7 a 2.6.20.20. Pokud vše půjde dobře, tak se CFS v22 dostane do hlavní větve Linuxu do verze 2.6.24. Více se dozvíte na KernelTrapu.

27.9.2007 07:06 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[Zdenek]

Tak. tak ve Fedore je uz mesice pouzivan.

[Martin Ždila]

ako zistim aky mam scheduler? cat /proc/..??

[frEon]

myslim ze kdyz nemas vyber mezi schedulerama, tak to v procu nebude. Jakou pouzivas verzi jadra? Jestli nemas tyhle s backportama, nebo nejakej release candidate 2.6.23 tak mas planovac staircase scheduler, nebo jak se to menuje.
jadro 2.6.22 mi ale velmi vyhovuje, a abych rekl pravdu noveho planovace se mirne bojim. precejenom je to uz lety proverena a dobra vec, CFS je novinka, buch vi co jeste nejruznejsi synteticke benchmarky nenasimulovali a jake chyby se jeste neprojevili. Viz treba nedavny problem s schet_yield() a workaround pomoci ktereho je to resene.
mym malim snem je backport xenu a posledniho mac80211 do kernelu 2.6.22. Take z duvodu ze s release candidatama mi nefunguje ztmavovani displaye na notebooku (regresi jsem zatim nehlasil, vzdy kdyz se ktomu zacnu chystat vyjde dalsi rc, a ja sem linej stahovat, kompilovat, zavadet, testovat, a pak to vracet zpet).

[michich]

Jestli nemas tyhle s backportama, nebo nejakej release candidate 2.6.23 tak mas planovac staircase scheduler, nebo jak se to menuje.

Staircase je scheduler od Cona Kolivase. Ten ve vanilla kernelu nikdy nebyl. Release kandidáty 2.6.23 mají CFS.

Viz treba nedavny problem s schet_yield() a workaround pomoci ktereho je to resene.

Používání sched_yield() v procesu s politikou SCHED_OTHER je prakticky ve všech případech bug.

[frEon]

aha tak v tom pripade beru zpet. a jak ze se ten docany jmenuje? je to SD?
no presto ze se to za bug da povazovat, nic to nemeni na faktu, ze se tahle fce nejak chovala a dalo se na to spolehnout (no vicemene, zalezi na poctu procesu se stejnou prioritou). Navic je nejak definovana a ted jeji chovani definici neodpovida (coz mi zas tak nevadi, kdyz je to stejne blbost). Ted se chova jinak, ba spis vseliak. Takze je to bug na oboou stranach?
Spis se bojim toho, ze to jeste neni proverenej planovac, muze se (a nemusi) objevit jeste spousta nejruznejsich problemu. Z toho mam "strach".
Muzete mi rict jeste neco o SCHED_OTHER a ostatnich politikach? Docela by mne to zajimalo.

[michich]

a jak ze se ten docany jmenuje? je to SD?

SD je právě Staircase Deadline, ten Conův. Dosavadní byl Ingův O(1) scheduler.

se tahle fce nejak chovala a dalo se na to spolehnout

Nikdy není dobrý nápad spoléhat na nedefinované chování.

Navic je nejak definovana a ted jeji chovani definici neodpovida

Pro SCHED_OTHER sched_yield() jednoznačnou definici nemá. Nedá se tedy říci, že by aktuální chování definici neodpovídalo.

Takze je to bug na obou stranach?

Podle mě jednoznačně chyba v programu. Ingo může chování sched_yield() nastavit tak, aby vzniklo ve starých programech co nejméně škody, ale chyba to zůstane vždycky.

Muzete mi rict jeste neco o SCHED_OTHER a ostatnich politikach?

Něco o nich je v manuálové stránce k sched_setscheduler(). SCHED_OTHER je výchozí plánovací politika. Procesy v ní mají dynamickou prioritu, dostávají přiděleno více či méně času podle toho, jak se chovaly v minulosti a podle své úrovně nice. SCHED_FIFO a SCHED_RR jsou real-timeové politiky, kde mají procesy statickou prioritu a jejich plánování je tak přesně dáno. Akorát u SCHED_RR je ještě řešen případ, kdy běží více procesů se stejnou prioritou tak, aby se občas mezi sebou střídaly.

[michich]

Ještě bych chtěl dodat, že ať už se chování sched_yield() udělá jakkoliv, vždycky se najde někdo, komu by vyhovovalo úplně jiné:

Programátor 1: Proč má sched_yield() tak slabý efekt? Já chci, aby dostaly čas všechny ostatní procesy, než se sched_yield() vrátí. Béééé!

Programátor 2: Proč je sched_yield() tak agresivní? To, že jsem ho zavolal, neznamená, že jsem chtěl, aby můj proces musel čekat i na procesy s nice -19. Béééé!

[frEon]

super dik za info, do manulaove stranky se kouknu

[michich]

nice -19

Dočasný mozkový zkrat. Tady mělo být kladné nice 19.

[frEon]

pochopili jsme

[Ondrej 'SanTiago' Zajicek]

> Nikdy není dobrý nápad spoléhat na nedefinované chování.

No ono v Linuxu (vzhledem ke stavu dokumentace) v mnoha pripadech nic jineho nezbyva.

[Ondrej 'SanTiago' Zajicek]

> Používání sched_yield() v procesu s politikou SCHED_OTHER je prakticky ve všech případech bug.

Co treba pripad, kdy proces primo komunikuje s hardware a hardware aktualne neni ready a neni moznost jak se nechat upozornit na to, kdy ready bude?

[michich]

Vím-li u takového hardwaru alespoň řádově, za jak dlouho mám jeho připravenost očekávat, tak radši proces před dalším pokusem na rozumnou dobu uspím, než bych se točil ve smyčce s sched_yield().

[Martin Ždila]

no ja mam Kubuntu Feisty

[frEon]

uname -r ? netusim jakej je kernel v kubuntu

[Stanislav Petr]

Proc CFS backportovali na 2.6.23-rc5, kdyz se na nem vyviji?

[m0rph]

Je to backport nejnovejsi verze CFS z gitu. CFS jako takovy uz bude v 2.6.23.

[Aleš Kapica]

Protože je text zprávičky jak tady, tak na rootu napsán pěkně zmatečně! Správně by to mělo být napsáno takto..

Completely Fair Scheduler který je v 2.6.23-rc8 byl pro velký zájem backportován na 2.6.22.8, 2.6.21.7 a 2.6.20.20.

[m0rph]

uz jste docela blizko, ale stejne se na puvodni zpravu (a na zminovane patche) podivejte jeste jednou :)

[atan]

Nemate nekdo CFS patch pro gentoo-sources 2.6.22-gentoo-r8? Nejde to aplikovat.