Hitrost Linuxovega jedra skozi čas

Brane2 je 19. nov 2010 ob 21:57 izjavil:

In kaj s tem ? Saj procesa čas niti ne zanima izven koncepta "ko paket pride". Pravzaprav ga niti to ne zanima. Kar se njega tiče, je paket vedno tam...

*sigh* Tole si napisal.

Brane2 je 17. nov 2010 ob 22:13 izjavil:

a tako na uč se zdi, da bi bila rešitev v dinamičnem dodeljevanju procesov v neko skupino glede na obnašanje ali še bolje posameznih threadov.

Ti nikoli ne ves kako se thread/process obnasa in kaj bo pocel. Lahko caka na I/O in lahko se izvaja (vse ostalo v bistvu ni pomembno). Nekega pametnega mehanizma, da poves vnaprej kateri proces mora dobiti vec ciklov in kateri manj nimas in ga ne mores imeti, ce bi ga imel, bi se mu reklo mod_clairvoyance.

Scheduler se trudi procesom dodeljevati cikle tako, da bo za uporabnika stvar cim bolj prijetna (v primeru desktop sistema). Ti ne ves kako se bo proces obnasal v prihodnosti, ti ves kaksno je njegovo trenutno stanje kaj bo pa cez pet minut pa nimas pojma. Lahko da bo proces naredil samo en update ure in zato porabil nekaj nano sekund CPU casa v tisti sekundi, lahko bo pa zacel z izracunavanjem PI-ja na zilijon decimalk in bo ponucal 999 milisekund CPU casa v tisti sekundi in bo posledicno tvoj desktop do nadaljnega precej neodziven.

Brane2 je 19. nov 2010 ob 21:57 izjavil:

Ti misliš, da se proces med čakanjem na IO vrti v prazni zanki ? Če ga butasto napišeš, potem že mogoče...

Ne. Se mi pa zdi, da se ne razumeva. Vsi procesi (ki se trenutno izvajajo) bi radi VSE cpu cikle, scheduler jim jih pa ne da. In nekega dinamicnega dodeljevanja ciklov se ne mores iti, ker ne ves kateri proces je uporabniku trenutno bolj pomemben in kaj bo ta proces pocel naslednjih pet minut. Je to browser window na desni ali oni na levi strani ekrana? Ali pa so to vsi procesi, ki si jih pognal v terminalu in tisti famozni make -j64. Ce jaz pozenem tale make in mi ga scheduler zbase nekam v eno klet, potem bo tale make trajal pet ur (na primer), ce mu pa da top priority se bo pa zakljucil v pol ure, vendar se mi bo tacas miska zatikala.

Scheduler ne ve a bi jaz raje zatikajoco misko ali bi raje nekaj vmes ali pa bi imel odziven desktop in mi je vseeno kdaj se make zakljuci. In sceduler tega ne more vedeti oziroma ugotoviti s kakrsnim koli monitoringom procesov, ki ni narejen na osnovi kaksnega vnaprejsnjega ugotavljanja in rangiranja procesov.

*sigh* Tole si napisal.

Brane2 je 17. nov 2010 ob 22:13:37 izjavil:
a tako na uč se zdi, da bi bila rešitev v dinamičnem dodeljevanju procesov v neko skupino glede na obnašanje ali še bolje posameznih threadov.

Ti nikoli ne ves kako se thread/process obnasa in kaj bo pocel. Lahko caka na I/O in lahko se izvaja (vse ostalo v bistvu ni pomembno). Nekega pametnega mehanizma, da poves vnaprej kateri proces mora dobiti vec ciklov in kateri manj nimas in ga ne mores imeti, ce bi ga imel, bi se mu reklo mod_clairvoyance.

Seveda veš. Če čaka na I/O, potem to valjda kernel ve. Če ne čaka na IO/MEM etc infrastrukturo, potem dela in porablja svoje cikle koristno.

Še več, lahko se ti zdi, kaj se dogaja v threadu. Če nek thread v vsakem timesliceou odpre novi fajl, potem se ga da dat v non-realtime skupino.
Če čaka na X11 interactive dogodek, potem se da thread dati v realtime skupino.

A recimo da tega ne počneš. Komot predvidiš situacijo v kateri se thread, ki dela z gui, sam s klicom rutine ali syscalla da v realtime subskupino, ostali v backendu pa v bulk.

Scheduler se trudi procesom dodeljevati cikle tako, da bo za uporabnika stvar cim bolj prijetna (v primeru desktop sistema). Ti ne ves kako se bo proces obnasal v prihodnosti, ti ves kaksno je njegovo trenutno stanje kaj bo pa cez pet minut pa nimas pojma. Lahko da bo proces naredil samo en update ure in zato porabil nekaj nano sekund CPU casa v tisti sekundi, lahko bo pa zacel z izracunavanjem PI-ja na zilijon decimalk in bo ponucal 999 milisekund CPU casa v tisti sekundi in bo posledicno tvoj desktop do nadaljnega precej neodziven.

1- pa saj to lahko vidiš v trenutku, ko se njegov timeslice konča. Še več, kernel že vodi tovrstno knjigovodstvo. Tako tudi dobiš podatek z ukazom "time". Ta ti pove, koliko časa je proces preživel v userlandu ( ko se je izvajal program), v kernelu ( ko so se izvajali klici) in pa wallclock time.

Ne. Se mi pa zdi, da se ne razumeva. Vsi procesi (ki se trenutno izvajajo) bi radi VSE cpu cikle, scheduler jim jih pa ne da. In nekega dinamicnega dodeljevanja ciklov se ne mores iti, ker ne ves kateri proces je uporabniku trenutno bolj pomemben in kaj bo ta proces pocel naslednjih pet minut. Je to browser window na desni ali oni na levi strani ekrana? Ali pa so to vsi procesi, ki si jih pognal v terminalu in tisti famozni make -j64. Ce jaz pozenem tale make in mi ga scheduler zbase nekam v eno klet, potem bo tale make trajal pet ur (na primer), ce mu pa da top priority se bo pa zakljucil v pol ure, vendar se mi bo tacas miska zatikala.

KO si bo browser zaželel updatat okno, bo sprožil ustrezni klic in ta ga bo lahko postavil v realtime skupino. Ravno tako "make -j64", Ko bo prišlo do klica za izpis/in/ali skrol, se bi strezen thread postavil v realtime skupino.

Scheduler ne ve a bi jaz raje zatikajoco misko ali bi raje nekaj vmes ali pa bi imel odziven desktop in mi je vseeno kdaj se make zakljuci. In sceduler tega ne more vedeti oziroma ugotoviti s kakrsnim koli monitoringom procesov, ki ni narejen na osnovi kaksnega vnaprejsnjega ugotavljanja in rangiranja procesov.

Lahkos e mu dokaj dobro sanja na podlagi tega, katere IO operacije nit zahteva ali izvaja, še raje pa s signalizacijo niti same. Pač daš niti za gui v realtime skupino.

Še več, lahko se ti zdi, kaj se dogaja v threadu. Če nek thread v vsakem timesliceou odpre novi fajl, potem se ga da dat v non-realtime skupino.
Če čaka na X11 interactive dogodek, potem se da thread dati v realtime skupino.

Se ti to zdi res smiselno gledat? :) Razmisli kako hitro se timeslice-i menjujejo in koliko casa bi porabil za ugotavljanje kaj nek thread dela.

Pa saj neke sorte knjigovodstvo se dogaja že sedaj. Sedaj bi k temu dodal le še malo knjigovodstva v interactive IO syscalle. Če rezultat sproži realtime trigger, gre thread v realtime skupino, sicer ne.

Temu knjigovodstvu, kot rečeno, bi se lahko izognil tako, da bi kot pisec programa sam zahteval prehod ustrezne niti v realtime skupino.

Jaz ti hocem dopovedati, da ti ves (precej priblizno) kaj se je dogajalo. Kaj se pa bo, pa nimas pojma.

Če programa ni pisal norec, se ti lahko precej dobro sanja. Če en thread sprejema in/ali oddaja interaktivne dogodke, se ti lahko sanja, da bi ga bilo dobro postaviti v realtime skupino.
Če jih bo čez sekundo nehal, big deal, pač ne bo kuril niti CPU časa. GUI zadeve reagirajo na dogodke. Če teh ni, zadeva stoji in čaka na dogodek.
Če dogodkov dalj časa ni, thread pa požira timesliceje, potem je počasi čas za vrnitev v bulk skupino.

Seveda, ampak preverjanje tega te bo na koncu precej drago kostalo. Ce bi se to tako zelo splacalo delati, potem bi se to ze pocelo.

Tega se ne počne zaradi tega, ker AFAIK sedaj ne moreš odločati o prioritete posamezne niti, le procesa v celoti. Tako ti bulk zadeve odžirajo čas za realtime threade.
Sploh pa, če bi dodali syscalle za nastavitev ustrezne prioritete za vsako nit posebej in tam postavili pametne parametre, bi komot pisci programov predelali source temu ustrezno in knjigovodstvo ne bi bilo potrebno.

BigWhale je 20. nov 2010 ob 12:31 izjavil:

Hec je v tem, da bi se potem vsak odlocil, da bo pa njegov program moral delati hitro in bodo ljudje stvari metali v realtime skupino tudi tisto cesar ne bi bilo treba.

Saj procesi imajo že leta dolgo nastavljene prioritete. V Windows odpreš Task Manager in pogledaš Base Priority za vsak proces posebej. Najvišje je Task Manager in Window Manager, nekateri so pa tudi pod normalno prioriteto. Na več od normalne prioritete se nastavijo programi za gledanje videa in peko optičnih medijev. Če je kakšen velik "number crunching", se pa nastavi na Low ali Below Normal. Itak je cilj programerja, da bo njegov program delal tekoče, ampak ne da bo na ta račun začel cel sistem štekati.

Spremljanje koliko CPU ciklov je porabil procesor ni požrešno, saj samo izvedeš RDTSC pred preklopom na drugo opravilo. Ne rabiš pa "spremljati", kaj počne proces, saj lahko dobiš prav dobro podobo o tem, če samo veš, katere kernel funkcije kliče. In kernel ve, kaj od njega programi zahtevajo...

The newest linux update, kernel – 2.6.38 features a number of enhancements that should offer a performance boost, particularly in parallel processing like multitasking, databases and other apps that require maximum resources. This kernel has been released only 10 weeks after the previous version, 2.6.37.

Linux 2.6.38 according to Linus Torvalds, comes with deep changes that should speed up the system, including the addition of new technologies such as automatic process grouping and transparent huge pages, and VFS – virtual file system enhancements.

The process-grouping approach will allow applications to divide the processor time more equitably, resulting in improved performance overall. Transparent huge pages increases the cache size for storing frequently consulted memory addresses, called pages. Traditionally, page sizes have been limited to 4KB, but modern processors support more larger sizes. With a larger page size, databases and other heavy workloads can be executed faster than before.

VFS has been made more scalable. Now, multithreaded workloads will be more scalable and single-threaded workloads will be executed faster. The favorite update according to Torvalds is the VFS name lookup change.

Performance enhancements are just a fraction of a new kernel because it brings a number of new features as well, driver updates and bug fixes.

The new linux kernel is really faster