tady v techto benchmarkach nedopadl BFS zas tak spatne:
http://www.phoronix.com/scan.php?…
To bude nejspíš kvůli tomu, že CFS napsali aby to běželo na tisícovkách CPU s vysokým výkonem v nějakých serverových úlohách.
A to BFS je napsané na druhý konec spektra, počítače s jedním socketem (ne NUMA), nicméně vícejádrové, pro úlohy na desktopu, kde chceme, aby počítač reagoval když kliknete.
Souhlasim. Posledni testy na telefonu s Google Android (viz posledni build od Cyanogen – http://www.cyanogenmod.com) pri pouziti BFS ukazuji znacne navyseni vykonu.
No, výkonu. Možná že video by mě to nakonec zakódovalo pomaleji… čert ví. Smysl toho scheduleru je skutečně v tom, aby vám desktop svižně reagoval, aby, když to trošku přeženu, vám netrval rekord v minách 230 sekund na linuxu, když na windows to dáte za 208. Autor to napsal kvůli sobě.
Podle mne se hadate zbytecne, protoze dany scheduler neni navrzen na zvyseni VYKONU, ale LATENCE. A to jeste za konkretni situace.
Vyse uvedene grafy podle mne latenci nemeri, i kdyz autor tvrdi, ze nektere z nich ano.
Nutno take poznamenat, ze vykonnost tohoto scheduleru je extremne zavisla na architekture. V pripade NUMA architektury podle mne muze mit vyrazne horsi vysledky, jelikoz nezohlednuje VUBEC rozdilne latence jednotlivych nodu.
Sice jsem tento scheduler nezkousel, ale mnozi co ano tvrdi, ze komplet odpadlo takove to zasekavani pocitace v mnoha situacich.
Nesouhlasim tedy s tvrzenim, ze je BFS horsi. Je jiny.
teší ma, že sa con kolivas vrátil a na vývoj kernelu nezanevrel. jeho patchset pre desktopy som používal až kým to nehodil za hlavu kvôli odmietaniu od hlavných vývojárov.
viď http://apcmag.com/…_kolivas.htm
Do you know what a normal desktop PC looks like? No, a more realistic
question based on what you chose to benchmark to prove your point
would be: Do you know what normal people actually do on them?
Feel free to treat the question as rhetorical.
Sorry, to prostě stálo za vypíchnutí :-)