A ~ 200 soros kernelpatch, amely drasztikusan csökkenti a latency-t

 ( trey | 2010. november 16., kedd - 19:36 )

A Phoronix figyelmét az egyik olvasója hívta fel egy, az LKML-re küldött kernelpatch-re. A tippadó szerint a kernelpatch jelentősen javította nála a "desktop élményt". Olyan tapasztalatokról számolt be, amelyet a Con Kolivas-féle ütemező patch-ek alkalmazása után tapasztalt. A Phoronix utánajárt és arról számolt be, hogy a kernelpatch "csodákra képes". Kiderült, hogy a szóban forgó, körülbelül 200 soros kernelpatch Mike Galbraith "automated per tty task groups" munkája. A patch jelenleg már a harmadik verziójánál tart, de ami a legfontosabb, ez a munka Linus tetszését is elnyerte, így hamarosan része lehet a disztribúciók által szállított kerneleknek is.

Linus az LKML-en megjegyezte, hogy milyen kellemesen meglepődött, amikor meglátta, hogy milyen kicsi a patch, ami ráadásul egyáltalán nem tolakodó és nem is csúnya. Szintén nagyon elégedett volt azzal, ahogy a patch az interaktív teljesítményre hatott. Linus szerint a patch az általa végzett triviális tesztekben (e-mail olvasás, webböngészés, weboldal görgetés miközben "make -j64"-gyel 64 szálon kernelt fordított) óriási előrelépést mutatott.

Linus itt ír bővebben a tapasztalatairól. A Phoronix készített két videót, demonstrálandó a patch pozitív hatásait. Az egyikben engedélyezve volt a patch által kínált szolgáltatás, a másikban nem.

sched_autogroup_enabled=0

sched_autogroup_enabled=1

A Phoronix cikke megtalálható itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Linux desktop eve..? :^)

Amugy milyen benak mar ezek a Phoronixesek, nem tudnak allvanyt hasznalni es osszevagni ket felvetelt...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Már megint nincs rajta sapka? :D
Korrekt szakmai hsz volt... :O
---
"Szép Mező Szárnya jel alatt született, Szívébe írva gyönyörű üzenet: "A világon élni csak hősként érdemes", Rajtad a sor, hallod, mondd tovább, Énekes!" P. Mobil - 1978

"Amugy milyen benak mar ezek a Phoronixesek, nem tudnak allvanyt hasznalni es osszevagni ket felvetelt..."

az nem olyan fun.

-na milyen már a bauxit leves Babi néni, egyszer jobb, kétszer jobb, háromszor?
--hát nem kegyetlenül kurva rossz, hanem aránylag szar...

:)

Kíváncsi vagyok milyen gyorsan kerülnek be a disztribúciókba, és hogy esetleg a nem folyamatos kiadások elgondolkodnak-e azon, hogy valahogy becsempészik ezt a frissítések közé.

Valahogy nincs kedvem saját kernelt forgatni, viszont így ránézésre musthave.

Nekem sincs, de a kíváncsiságom győzött.

androbit.org - Informatikai portál és könyvtár

"...de ami a legfontosabb, ez a munka Linus tetszését is elnyerte, így hamarosan része lehet a disztribúciók által szállított kerneleknek is."

Szépen összefoglalja, hogy mi alapján működik a linux kernel fejlesztése.

--
Kodály Zoltán azt mondta: "Legyen a zene mindenkié". Én inkább neki hiszek mint az ASVA-nak.

Neked is azt tanították az oviba, hogy nem létezhet alternatív kernelfa?

+1, azon kívül, hogy egy alternatív rendszermag neve nem lehet Linux, bárki szabadon lemásolhatja és terjesztheti.

... és élvezheti a backportolás minden gyönyörét.

Nehúzd fel az agyam. Kezded a hülyeséget. A dolog azért működik mert valaki irányítja. A kritika az, hogy az kerül be a dologba, ami tetszik az irányítónak. Hát persze, minek kellene belekerülni ami nem tetszik neki? Sok ilyen kiakadás volt, és senki nem mondta, hogy a Linus által csinált dolog a legjobb, DE működik. A kritika az a probléma, mivel nem akarja átvállalni az alternatív kernelfával járó munkát, és nem bízik abban, hogy meg tudja győzni a hozzájárulókat hogy inkább az ő fájából induljanak ki. A kritikusok (ha nem individualizmusról lenne szó) rég megalapíthatták volna Linux Kernel Engineering Task Force vagy valami tökömtudja mit amiben szavazgatva kiválasztanák a beolvasztásra szánt technológiákat.

huh. még itt felhúzzák az agyad.

"A kritikusok (ha nem individualizmusról lenne szó) rég megalapíthatták volna Linux Kernel Engineering Task Force vagy valami tökömtudja mit amiben szavazgatva kiválasztanák a beolvasztásra szánt technológiákat."

megszavazhatták volna, aztán linus ugyanúgy telibeszarta volna. milyen hasznos lenne egy ilyen, valóban.

Katedralis es bazar nem rossz konyv. Leirja a lenyeget ezzel kapcsolatban.

Amennyiben az lenne a konszenzus, hogy a kernel rossz, es azert rossz, mert Linus hibas dontesek sorozatat hozta, akkor mindenki uvoltve kovetelne linuxkerneles gittegyletet. De nem ez a helyzet. Gondolhatjak nehanyan ugy, hogy jo lenne egy linuxkerneles gittegylet, de nincs senkinek sem erdekeben ezt felvallalni.

Gyozd meg a top 20 kernelfejlesztot, hogy erdemes forkolni. Ha sikerul, van mirol beszelni. A tobbi nem szamit.

A masik modellt egyebkent BSD-nek hivjak. Nem mondom, hogy rosszul mukodik, vagy hogy nem jobb a linuxos modellnel, de kello lenduletet azert nem birt begyujteni eddig.

Flame nelkul, milyen lendulet hianyzik belole?

1300 diobel csakanyos. 200 ceg tamogatasa (fejlesztokkel).


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Lendulet alatt en most csak azt ertettem, hogy nagyobb tabort tudjon gyujteni, amivel konnyebben valik megkerulhetetlen tenyezove. Ugy tekintsenek ra, hogy, aminek fontos volt megirni a Linuxos portjat, annak erdemes legyen megirni mondjuk a FreeBSD-s portjat.

Bar nem ertek pl. a FreeBSD-hez, de en ugy latom, hogy a sajat kis zart vilagaban letezik. Amit ok irnak/portolnak ra, az van, mas szinte semmi. Ez jo, mert konzisztens a cucc (legalabbis komoly kontrollja van a governing boardnak). Ez mondjuk szerveruzemelteteshez eleg (talan meg hasznos is), de szerintem tobbre nem.

A BSD nem akar Linux lenni.

Hát azért elég gyakran belefutok az olyan howto-kba, amik úgy kezdődnek, hogy aszondja:

# echo "linux_load=yes" >> /boot/loader.conf
# echo "linux_enable=yes" >> /etc/rc.conf
# echo "proc /compat/linux/proc linprocfs rw 0 0" >> /etc/fstab

--
trey @ gépház

Ahhoz mit szólsz, hogy idén már az előzsűrin +7 szavazatszámmal kiesett a linux a HOVD "Kedvenc szerver operációs rendszer" szavazásán? ;)

Komolytalan? :)

--
trey @ gépház

Tekintve hogy nem volt a HUP-on még 8 ember se aki leszavazta volna a módosítást, valóban az ;)

Tavaly ~ 700 ember volt, aki megtette a megfelelő időben. Idén is lesz szavazás. 8 troll nem csinál tavaszt. ;)

--
trey @ gépház

Nem az volt a kérdés, hogy áthágod-e a szabályaid hogy csakazértis szerepelhessen a kiszavazott Linux. ;)

Arról sosem volt szó, hogy az előszavazás ügydöntő lenne.
Ajánlásokról ("kérelmek") volt szó.
Egyébként meg ez trey oldala, nyilván arról fogunk szavazni, amiről ő jónak látja.

Sir yes sir!

A HOVD-os kérdés felvetését nem érted, vagy azt, hogy miért nem reagáltak tömegével a szandálos binugzosok egy olyan felvetésre, ami max flamebait-ként értelmezhető?

Bizonyos teruleten pedig erdemes lenne tanulni. A linuxos arcok kepesek voltak "megfertozni" a ceges donteshozokat a technologiaval. Hogy erdemes vele szamolni, erdemes vele foglalkozni, eroforrasokat rendelni hozza. A linux konnyebben er el az emberekhez.

Mas teruleten persze nem kell tanulni. Egyreszt nem masolni kell a linuxot, mert akkor nincs uj ertek teremtve (mar sokszor felmerult, hogy a linux a ma letezo disztribuciok 95%-anak leepitesevel semmit sem veszitene, sot). A BSD-s vilagnak a fejlesztesi/minosegbiztositasi modellje lehet, hogy jobb linuxe, de akkor ezt meg kell mutatni. Foldbe kell dongolni a linuxot relevans teruleteken (teljesitmeny, biztonsag, virtualizacio), az alkalmazasok szeles koren, ami bebizonyitja a ketkedoknek, hogy a BSD-s fejlesztesi modell kepes rengeteg extra erteket adni annak, aki hajlando adoptalni az eredmenyeket.

gomb nyomásra gyönyör nem fog összejönni. szar hogy backportol-ni kell? nem értem mire mondod ezt. szoba festésnél de szar hogy fel kell mászni a létrára?

itt lehetőségek vannak. ha valaki akarja, fork-olhatja ami neki tetszik. ja hogy munka van vele?? ez a cudar valóság.

Mintha Linus lenne a vilag egyetlen projektvezetoje.....

Ha nincs megfeleloen eros vezetes, a projekt szetesik. Lehet biralni Linust az egyes technikai dontesek miatt, de maga a fejlesztesi modell mukodik.

Most igazabol mindegy, hogy egy ember, nepszavazas, vagy kozponti bizottsag dont, a dontesek eredmenyei es a kovetkezmenyek szamitanak.

Naja, szep dolog az opensource, de a "totalis demokracia" (barki commit-alhatna amit akar) az totalis kaoszhoz vezetne, valami szervezodesi forma csak kell a dolgok kezelesehez. Ennek persze az a kovetkezmenye, hogy az adott vezeto/vezetok dontese lehet akar hibas is neha, de meg mindig jobb, mintha "barki csinalhat barmit" szitu lenne, az eseteg nagy tobbsegeben legalabbis. Marmint szerintem ...

Arrol nem beszelve, hogy a szinten agyonhype-olt git is csak egy ilyen diktator mellett valik egyaltalan hasznalhatova 5 fosnel nagyobb fejlesztocsapatban.

+1

Mert máshol demokratikus szavazás van mi?
Theo meg Steve csak azért van, hogy megnyissa a szavazást, ugye?!

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Lassan erdekelne egyebkent, hogy van-e olyan anarcho-demokratikus fejlesztesi modell, ami mar produkalt a fentiekkel osszemerheto eredmenyt.

Mert en pl. nagyon nem csipem, amit az Apple csinal, de az eredmenyeik Steve Jobs hajcsarkodasa mellett letagadhatatlanok, sot tanitani valoak.

Projekt menedzsmentre gondolsz...? Ahhahh ;]
Borzasztó dolog, amikor az ember először találkozik vele, de szokható

:)

itt a dolgok nem a menedzsmenttől függnek, hanem hogy linusnak milyen hőmérsékletűre sikerül a kávéja

Tehát projekt menedzsment mégiscsak :)
Isten hozott a valóságban

max sok helyen ezt annak csúfolják. attól még nem lesz az.

Kezd kissé parttalanná válni a dolog. Láttam kis és nagy cégeknél, hogy mi folyik. Stílusban és prezentációban van különbség, lelki mechanizmusban nem sok. Lehet ezen még pörögni, de kicsit értelmetlen.
Ha nem értesz vele egyet, lehet, akkor ne használd, ami közvetve/közvetlenül tőle származik. (vagy ms bullshit módra: csináld te, jobban)

ok.

a "csinálj jobbat" bemondást az openszósz hívők szokták hangoztatni btw.

ms alatt mark $huttleworth-ot érti ;)

hehh, és tényleg, kicsit ironikus egybeesés.

:)
Ezt a viccet windows-al ismerem, de a lényeg, hogy szerinted van tisztán szakmai alapon működő pm, szerintem meg csak papíron. KKV szint felett meg már bőven politikai és karrier érdekek is bejátszanak, de nem akarlak a hitedben megingatni.

nem azt mondtam, hogy tisztán szakmai alapon, de legalább legyen valami köze hozzá.

Ennek azért van egy kis Dunning–Kruger zamata.

Ezek alapján akarod megítélni?! Neked úgy tűnik, hogy semmi szakmai nincsen ezekben a dolgokban? Akkor kár is tovább vitázni erről, mert ezek szerint arra dőlsz, amerre az IT bulvár fúj.

Látod a szempontjait a Gnome-KDE esetében? Láttad a kódot, amit fosként minősített? Beszéltél azokkal az emberekkel, akik végül bevágták a durcit mint meg nem értett zsenik?

Azzal meg én sem tudok mit kezdeni, hogy egy hosszabb projekt esetében _mindig_ vannak személyes ellentétek, és senki nem lesz képes kibogozni annak a szakmai hátterét. Nemhogy egy kívülálló sokadlagos információk alapján.

"hozzá"

Hát elég durván fogalmaz, de számos szakmai szempontot említ, és azokban teljesen igaza van.

subscribe

azért az elgondolkodtató, hogy linus azt hitte, a böngésző a hálózat miatt volt lassabb a patch nélkül.

mert triviális, hogy nem így van. elég lett volna beülni egy windows elé, és megnézni, hogy de érdekes, hogy feleannyira lagzik. biztos a hálózati stack miatt van, mert a grafikus driverek meg az egész gui híresen jók linuxon. hmm...

Lehet azt hitte, hogy ez a normális :D

androbit.org - Informatikai portál és könyvtár

vagy csak simán hozzászokott, így fel se tűnt.

Ez kb olyan, mint amikor haverom gyenge gépen nagy erőforrást igénylő játékkal játszott. Szaggatott, mint a fene és egy idő után már nem látta a szaggatást.

androbit.org - Informatikai portál és könyvtár

Nem kizárt, pár hét linuxon firefoxozás után windowson firefoxozni iszonyat mód felemelő élmény.


suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.

megnyugodtam, hogy nem vagyok egyedül ezzel.

Ha egész életedben egy pöcegödörben élsz, már nem is érzed a szagát. :)


suckIT szopás minden nap! A javaisten bármikor lealázza a C-s webszervered grizzlyvel, pl.

xar ügy.

Aki egész eddigi életét egy sátor tetején töltötte, annak Sátoraljaújhely. :)

Ne feledd, most kezdődik életed hátralévő része!

firefox valoban sokkal gyorsabb Windowson, mint Linuxon,de ellenben a Chrome teljesen korrekt sebesseget produkal Linuxon is. Miota Linuxozok egyre rosszabb a firefox, ezekszerint a Windowsos azota jo maradt

Meg a masik ilyen az openoffice.org, de az Windowson is lassu mondjuk, de ezt a 2 programot leszamitva, meg az Amarokot nekem Linuxon minden <1s alatt elindul

ff4 nálam fordítva.

ff4 egyelőre tényleg nagyon alfás.

szar a linux.

persze, mert azt csak make -j64 melletti böngészésre lehet használni.

Miközben a háttérben pörög a glxgears, egy hd mozi, és a fennmaradó processzidőben az ufókat keressük. Átlagos :)

Imho, ha 200 sor ennyit segit, az pont hogy azt bizonyitja, hogy annyira nem is szar, nem kellett hozza tobb tizezer soros patch, hogy korrigaljon egy problemat ...

Lehet így is értelmezni, meg úgy is, hogy annyira szar, hogy néhány soros javítás is csodákat képes művelni... ;)

Ketlem, adok neked egy veletlenszeruen osszezavart kernel forrast, javitasd meg 200 soros patch-el, hogy mukodjon :) Nyilvan ha keves sorban problema javithato, akkor az alapokkal nincs legalabb akkora problema a jelek szerint. Legalabbis bizonyos szempontbol, mas teruleten meg lehet :) Nade komolytalanra forditva a szot: pont a szarra jellezo, hogy kvazi "ah, ezt ujra kell irni" a reakcio, mivel azon par ezer soros patch sem segit (ha a patch merete nagyobb mint az eredeti forras, az mar gyanus ...)

Azért lehet hogy ráférne egy újraírás a kernelre. Nem azért mert szar, hanem mert általában a programok eljutnak idáig, és általában jót tesz nekik egy rewrite. Linus nem gondolkodott még a 3-as verzión?

Csináltál már ilyet ? :) . Szerintem majdnem akkora lenne újraírni, mint amekkora melót eddig belefektettek. Tuti lenne a kudarc.

Őszintén szólva nem. És nem is mondom hogy tudom mit beszélek :) Viszont hallani sokfelől, hogy xy program új verzióját teljesen újraírták, és ezért jobb, gyorsabb, tisztább.

És hát ugye logikus, hiszen ha valamire építkezel, akkor az alap megköti a kezed, ha pedig teljesen újraírod a programot, akkor azt már az új ismeretek, új elképzelések szellemében lehet készíteni.

Nyilván egy kernel azért sokkal nagyobb munka, nem igazán gondoltam ebbe bele, de csak lehetne valamit máshogy/jobban csinálni.

> Azért lehet hogy ráférne egy újraírás a kernelre.

Folyamatosan írják újra. Sorok jönnek, mennek ...

Itt egy jó cikk az újraírás vs kódtisztítás témakörben. A fickó azt hiszem MS alkalmazott volt.

Nem csak Ubuntu van. Ott nekem is akadozobbnak tunt, mint mas Linuxal.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Bocs, de nem értem hogy jönnek ide a grafikus driverek. A patch az ütemezőt javítja, ettől szűnt meg a latency, és egyébként is az egész latency probléma csak magas loadnál állt fenn.

ezt miért nem írtad meg Linusnak 1 héttel ezelőtt?
biztos örült volna, a te ázsiód pedig nagyot nőtt volna :D

hehe

+1 :)

Az meg elgondolkadtatobb, hogy az otlet tole szarmazik. Es, hogy foleg akkor jo ha terminalbol sokszalas CPU zabalo dolgot inditasz.

FYI: Networkot hasznal a tavol fajlrendszer is, vagy elosztott forditas.
Nagyon meglepodnek, hogyha ennek patchnek eszlelheto hatasa van ha csak bongeszel.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Az meg elgondolkadtatobb, hogy az otlet tole szarmazik."

egyre cifrább. a-t mond, b-t ír, c-re gondol és d a helyes? :)

"FYI: Networkot hasznal a tavol fajlrendszer is, vagy elosztott forditas. "

ez bizony teljesen tipikus use case.

"foleg akkor jo ha terminalbol sokszalas CPU zabalo dolgot inditasz."
"Nagyon meglepodnek, hogyha ennek patchnek eszlelheto hatasa van ha csak bongeszel."

állítólag nincs, éppen ezért is érthetetlen, hogy a hálózatra gyanakodott.

"Az meg elgondolkadtatobb, hogy az otlet tole szarmazik."

egyre cifrább. a-t mond, b-t ír, c-re gondol és d a helyes? :)

Linus ötlete volt, valaki más implementálta, háromszori javítás után már egészen jól néz ki. Mi ebben a cifra?

Végülis semmi, ez kb. a Linux standard... :)

háromszori javítás után már egészen jól néz ki

Viszont legalább ha valami már stabilan rendelkezésre áll, azt a lehető leghamarabb beleteszik. Nem várnak vele két évet marketing-okokból. (Hogy a hülye júzer kénytelen legyen kétszer a zsebébe nyúlni.)

flame off

ja. ck.

Viszont legalább ha valami már stabilan rendelkezésre áll, azt a lehető leghamarabb beleteszik.

Viszont legalább ha valami már stabilan rendelkezésre áll, azt a lehető leghamarabb elrontják újra.

Fixed.

Egyszeri rendőr: a fuvarlevelen jam van, a sofőr dzsemet mond, a platón meg lekvár van:)

"ez bizony teljesen tipikus use case."

Azt mar tobbszor bizonyitottad, hogy fogalmad sincs rola, hogy mi az ami gyakori feladata egy Linux rendszernek, es hogy mire akkarjak hasznalni sokan.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

oké, várom a "szoktál-e rendszeresen hálózati fájlrendszerről fordítani linuxon?" szavazást, aztán ha a számok téged igazolnak, elfogadom a fikkantásod, addig csak alaptalan oltás.

Forditas tavoli gepen, halozati file-rendszeren.

Eddig az osszes cegnel, ahol dolgoztam (na jo 4-bol 3-ban) pont erre hasznaltak Linuxot. (Az egyikben egy unix-ot, de azota ki tudja, lehet, h. linux-ra csereltek).

my 2 cents: a hálózati kódot nem Linusnak kéne gatyába ráznia, ha az a bűnös?

Meg itt van a patch:

http://marc.info/?l=linux-kernel&m=128978361700898&w=2

már akit érdekel.

--
GPLv3-as hozzászólás.

Egy teljesen naiv kérdés, tuti, hogy én nem értek valamit, de ennél a résznél:

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

így nem lenne egyszerűbb?

+ if (ag) kfree(ag);
+ WARN_ON(1);

Maris megvan a fenti patch magyar 197 soros uberelese.....

Torolve

Szerk.: igazad van.

Mivel az else után egyetlen utasítás van csak, így szerintem mindegy, hogy utána } jel szerepel-e, az már nem ehhez az if-else szerkezethez kapcsolódik, tehát szerintem mindegy, mi van utána.

igazad van, elnéztem, lásd lentebbi írásom.

Ezeket a több sorba írt, blokk kezdő, záró jelek nélkül használt szerkezeteket nagyon könnyű elnézni (az előbb én is így tettem).
célszerű ezeket vagy egy sorba írni, vagy kirakni a blokkot.

pl.: 
	} else
		WARN_ON(1);

helyett

	} else {
		WARN_ON(1);
	}

vagy

	} else WARN_ON(1);
	    
a célszerű.

Logikailag igazad van; közben lehet hogy az egyik csak debug vagy bármi más miatt csak ideiglenesen van ott és el fogja távolítani. Írd meg neki az észrevételedet és majd meglátjuk mit válaszol.

Kódot nem befolyásolja.
Valszeg egy korábbi (debug)kódrész maradványa.

Gondolom a WARN_ON kiírja a __LINE__ -t, és akkor a két WARN_ON jobb lehet a fejlesztőnek, mint egy.

neha meglepsz

--
NetBSD - Simplicity is prerequisite for reliability

Hát ez azért nem hasonlítható a Con Kolivas féle cucchoz.

Itt ha jól értelmezem a low latencyhez az kell, hogy egy groupba kerüljenek a számításigényes taszkok.

Ami meg most ebben a patchban automatikusan tty-hez kötött.

Azaz ha tíz terminálon indítok videókódolást akkor az belassít, ha egy terminálon indítom mind a tízet akkor meg kevésbé.

A Con Colivas féle ütemezőben nem csak ennyi a trükk ugye? Vagy tévednék? (Vagyis, hogy az többféle felállásban is low-latency? Csak mert ott is ez a make -jx-es tesztelgetés dívik, amire bőven elegendő ez a trükk...)

Nem hát. A Kolivas féle cucc egy komplett új ütemező ami más elvek mentén fejlesztett (desktop workload), és lecseréli a CFS-t. Ez meg egy kiegészítés a CFS ütemezőhöz (automatikus cgroup létrehozás ha jól értem bizonyos paraméterek alapján). Elvben idáig is be tudtál volna állítani hasonlót kézzel a cgroup megfelelő paraméterezésével, de majd a kernel guruk megmondják a tutit.
Az egész ott van elb*szva, hogy anno Ingo-ék nem engedték a moduláris ütemező patcheket a kernelbe tenni, szóval most az "egy ütemező mind felett" a követendő út szerintük, ami minden workload-hoz megfelel a beágyazott rendszerektől a 4096 CPU-s szörnyekig. Ha moduláris ütemező frameworkje lenne a linux kernelnek, akkor akár futási időben is változtathatnád az ütemeződet mondjuk a CFS és a BFS között.

Feltéve, hogy egyáltalán sikerült megoldani a moduláris ütemezővel járó egyéb problémákat.

> szóval most az "egy ütemező mind felett" a követendő út szerintük

Ami azért jó szerintem, mert így napvilágra kényszerülnek bizonyos rejtett információk. Önmagában abból, hogy két ütemező ugyanarra a workload-ra máshogy viselkedik, nem lehet tanulni. Abból, hogy az "egy" ütemezőt hogy kell módosítani, hogy bizonyos workload-ok jobban viselkedjenek, abból lehet tanulni.

> Ha moduláris ütemező frameworkje lenne a linux kernelnek,

Én a modularitást csak akkor venném elő, amikor az "egy" ütemező kódja már eléggé bonyolult ahhoz, hogy a modularitás bevezetése számottevő előnyt hozzon az if()-ek és egyebek kiesése miatt.

Hmm, nem tudom nekem ez így szimpatikusnak tűnik:

http://www.princeton.edu/~unix/Solaris/troubleshoot/schedule.html

Tehát, ha nálam az is tetű lassú, ha a böngésző tartalmát újra kell rajzolni, mert levettem róla egy másik ablakot, akkor ez a patch se fog javítani a helyzeten, ugye? Vagy próba cseresznye?

Rajtad egy kompozit ablakkezelő fog segíteni.

A fenebe is, igazad lett.:) koszonom

http://ck-hack.blogspot.com/2010/11/create-task-groups-by-tty-comment.html

Remember, I already had developed a hierarchical tree-based penalty patch for BFS and blogged about it here. I can do it in a 10 line patch for BFS, but it introduced regressions, which is why I dropped it.

És ez így mindenféle fennakadás nélkül be fog kerülni a mainline kernelbe CFS-hez, ezúttal sem csalódtam, csak így tovább.

Felteszem Linus megnézte a videót, oszt hö hát gyorsabb, hát akkor tegyük má bele a kernelbe, mert mér má ne hö.

A másik meg, hogy Linus elvan örömében, hogy minden milyen szépen megy make -j64 mellett:

I'm also very happy with just what it does to interactive performance.
Admittedly, my "testcase" is really trivial (reading email in a
web-browser, scrolling around a bit, while doing a "make -j64" on the
kernel at the same time), but it's a test-case that is very relevant
for me.

Con Kolivas reakciója:

Again, I can't for the life of me see why you'd optimise for make -j64 on a quad core machine. It is one workload, unique to people who compile all the time, but done in a way you wouldn't normally do it anyway. It is not going to magically make anything else better. If for some god-forsaken reason you wanted to do that, you could already do that with nice, or even better, by running it SCHED_IDLEPRIO.

Köszönjük Linus.

De vajon mit szól mindehez Molnár Ingo?

Felteszem Linus megnézte a videót, oszt hö hát gyorsabb, hát akkor tegyük má bele a kernelbe, mert mér má ne hö.

Szerintem kicsit hülyének nézed a srácot.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Nem is tudom, egy patch ami ugyan előnyös nagy processzorterhelés (vagyis workload) mellett, de a legkevésbé sem az minden más helyzetben nem éppen ésszerű.

Meg a make -j64 "testcase" sem tűnik nagyon relevánsnak és tipikusnak, bár láthatóan ez csak Linus számára nem triviális.

Nem is tudom, egy patch ami ugyan előnyös nagy processzorterhelés (vagyis workload) mellett, de a legkevésbé sem az minden más helyzetben

Az honnét derül ki, hogy más helyzetben nem előnyös? Komolyan kérdezem, nem kötekszem.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Those following the development of the patches for interactivity at massive
load, I have COMPLETELY DROPPED them as they introduce regressions at normal
workloads, and I cannot under any circumstances approve changes to improve
behaviour at ridiculous workloads which affect regular ones. I still see
precisely zero point at optimising for absurd workloads. Proving how many
un-niced jobs you can throw at your kernel compiles is not a measure of one's
prowess. It is just a mindless test.

Ez nem jelenti azt, hogy CFS-en is regressziókat okoz, mint BFS mellett, de potenciálisan okozhat.

Valaki biztosan leteszteli alaposan. Kíváncsi leszek az eredményre.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

"Felteszem Linus megnézte a videót, oszt hö hát gyorsabb, hát akkor tegyük má bele a kernelbe, mert mér má ne hö."

Nem.

Nem hát hö. Kifejtenéd?

Nyilvánvalóan nem a videó alapján döntött.

Again, I can't for the life of me see why you'd optimise for make -j64 on a quad core machine.

Javítson ki valami hozzáértő, ha félreérteném, de szerintem Con Kolivas itt csacskaságokat beszél. A "make -j64" csak tesztelés miatt volt használva, nem? Szó sincs róla, hogy erre optimalizálták volna a patch-et. Vagy tévedek?

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Én úgy értelmezem, azon akadt fenn, hogy normál körülmények között miért is használná ezt a kapcsolót valaki egy négymagos gépen.
Vagyis nem tipikus felhasználás ez, és valójában kevés embert érint.

...ha pedig mégis jó indoka van rá, eddig is megtehette a fent felsorolt módokon (nice, SCHED_IDLEPRIO).

Szerk.: Szerintem azt vonta kétségbe, hogy normál körülmények között is ekkora javulás lenne.

Hát, ezt eléggé könnyű kipróbálni. :)

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Én is kíváncsi lennék, mennyire változik vele egy-két dolog.

Múltkor talán a KDE4 alap keresőjébe írtam valamit és iszonyatosan leterhelte a gépet. Gyakorlatilag semmit nem lehetett csinálni közben. Ha ilyen eseteken is javít, már régen megérte. :)

Szerk.: Csak kiegészítés - valójában kevés embert érinthet és ők sem így futtatnák, ahogy írja fent...

...de én arra lennék kíváncsi, a teszten kívül milyen előnyöket hoz.
Nekem nincs gondom a gépem teljesítményével, de sikerült már olyan terhelést produkálni, amikor földhöz vágtam volna... bár ez még az előző rendszeren, de nyilván most is lehetne.

Lehet hogy annak inkább van köze az io ütemezőhöz meg a fájlrendszerhez mint a processzor ütemezőhöz.

Lehet, sőt...

Ha nem mobilneten lógnék, akkor már forgattam volna egy kernelt, és mondanék egy szubjektív véleményt, de azzal sokra nem mennétek :)

A ~ 200 soros kernelpatch, amely drasztikusanHAHAHA DISREGARD THAT, I SUCK COCKS

csodálom, hogy ez még nem volt ...

a phoronix szónál majdnem abbahagytam, de sajnos nem.

Bár nem értek hozzá annyira, de találtam egy ilyet:
CHROMIUM: config: enable cgroup-based group scheduling

"put the active tab processes into a "foreground" group and the backgrounds tabs into a "background" group"
Első olvasatra értelmes gondolatnak tűnik.

Jól értem, hogy hasonló bash scripttel (meg ugye a kernel patch-vel) megoldhatom, hogy ne haljon le a videólejátszás, ha a háttérben tömörítgetek?

ahogy feljebb is írták szerintem, most is adhatsz minden folyamatnak külön prioritást a nice és ionice parancsokkal.

Adhatok, de valahogy nem nagyon használ. max nice-t adtam az mplayer folyamataimnak, és így is beszaggatott a videó, amikor másik monitoron chrome alatt lapot váltottam. Pedig az ember azt várná, hogy max prioritáson a többi alkalmazás megmoccanni se tud.

szerintem fordítva, a tömörítésnek adjál kis prioritást.

De - mint azt írtam - nem csupán a teljesítményigényesebb háttérfolyamatok (mint tömörítés, ilyesmi) közben tapasztalok olyat, hogy a videó beszaggat, a lejátszás megakad, hanem az általános programok funkcióinál. Pl előugrik egy notify. mozgatok egy ablakot (!), lapot váltok chrome-ban, vagy frissítek egy aloldalt.

Már az, hogy ha valami miatt intenzívebben swap-el a rendszerem megakasztja a dolgokat.* Egy fájlmásolás is lassít annyira, hogy nem nagyon tudok pl youtube videót nézni közben akadásmentesen (nem is értem miért terheli az a cpu-t annyira).

* kubuntu + chrome + egy terminálablak + egy dolphin ablak + egy kate általában nyitva van, ez már nem nagyon fér el az 1 gigában valami oknál fogva, és sokszor lapozok.

btw egy acer one netbookot használok.

az első bekezdeéshez: videó lejátszás közben egy netbook-nál el tudom képzelni hogy beszaggat az ablak mozgatás, persze kérdés milyen felbontású a videó stb. függ a videó gyorsítástól is, az meg a videó driver-től.

ha meg sokat lapoz a rendszer, akkor azon már nincs mit tuningolni. kisebb erőforrású rendszert tegyél rá imhó, a kubuntu-nak egy netbook 1 GB ram-mal kevés valószínű.

Igen, sajnos kevés az 1 giga, gondolkodtam a bővítésen, egyszer szét is szedtem a netbookom, viszont csak 512 megát találtam benne, másfél gigára bővíteni meg annyira talán nem nagy teljesítménynövekedés :D hogy hol a másik 512 arról fogalmam sincs :D

Az viszont sajnálatos hogy 1 giga nem elég ma egy modern rendszernek. A windows 7 ami később jött ki mint a kde nyugodtan fut tesóm 768 mb ram-os gépén, szóval nem igazán értem hogy miért van ez így.

Persze használhatnék más disztribet, de a kate nagyon a szívemhez nőtt, egyszerű, de programozásra nagyon jó szövegszerkesztő, ráadásul kde alatt egyébként is sok hasznos dolog van, ami miatt nem szívesen mondok le róla.

egyetértek, jó rendszer, viszont a cache sokat számít. ha az alaprendszer (nem tudom, csak tippre) megeszik tegyük fel stabilan 3-4-500 MB-ot, egy böngésző megint pár százat több lap után, és a többi, akkor már nincs cache, amelyből a visszanyitott programok fájljai, vagy adat fájlok tudnának újratöltődni.

ugyanez win7-nél is, ha nincs ram, ott se lesz sok cache, és tölteni fog a vinyó a használat nagy részében.

jó megoldást nem tudok javasolni :)

Hát, nem is nagyon van. Egyszer ha gazdag leszek akkor veszek egy macbook air-t, mert az kicsi gép, és marhaerős (muszáj nekem a netbook méret sok cucc mellett gépet cipekedni). Majd jól meglincselnek, de telepítek rá kubuntut :D

Ezzel kapcsolatban van valami fejlemény? Ki lehet már valamelyik distroban próbálni?

Szerk: kipróbáltam az Ubuntu 11.04-ben, eléggé meggyőző.

egy bővebb blog bejegyzés jó lenne :)

Minden kívánságod így teljesüljön! :)

köszi! :)

Köszi!

--------------------------------------------------------------------------
színes