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

Kernel

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.

( atomheart v | 2010. 11. 16., k – 18:54 )

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$%#$#%^*^"

( manfreed (nem ellenőrzött) | 2010. 11. 16., k – 19:01 )

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.

( grouder v | 2010. 11. 16., k – 19:06 )

"...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.

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.

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.

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.

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 ...

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)

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.

( bervi | 2010. 11. 16., k – 20:10 )

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...

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

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 ...)

Ő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 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.

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ű.

( szemet | 2010. 11. 17., sze – 09:28 )

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.

> 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.

( Zaneck | 2010. 11. 17., sze – 13:13 )

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

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)

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.

É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.

( skynetpro | 2010. 11. 17., sze – 18:09 )

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

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 :)

( zolpet | 2011. 03. 31., cs – 12:24 )

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ő.