Tvikanje Gnu/Linuxa

i kakve to ima veze ? statican ili ne kad je cijela fizicka memorija fragmentirana skupa sa blokom u kom je kernel

s tobom stvarno nesta nije u redu ? imas problema sa zakljucivanjem ?

Kernel se nikad, ali nikad ne "šalta" po memorijskim adresama. Zapiše ga se u taj blok, on ostatak mapira u virtualnu memoriju i dalje po aplikacijama dodjeljuje koliko tko zatraži (ili odbije zahtjev). Tu idu u priču i NX, PAE...

A sad malo o toj nesretnoj fragmentaciji. Ako je nešto zauzelo prva 3 bloka, u 4. i 5. nešto drugo, naravno da će doć do fragmentacija kada aplikacija 1. (kojoj su blokovi 1-3 postali premali) zatraži još memorije (dakle 6 i dalje). To ne možeš izbjeć jer ako aplikaciji treba 8 MB za neki podatak, treba joj i dovoljno velik adresni prostor. Možeš smanjiti veličinu blokova i tako prividno smanjiti fragmentaciju (to je ona tvoja "manja" potrošnja) ili možeš ić seliti alocirane blokove naokolo što nije baš ok za performanse.

Ukratko - hrpetina gluposti. Super-optimizirani kernel za marginalne dobitke. BTW, živo me zanima kako bi se to sve pokazalo kad bi pokrenuo par većih aplikacija i krenuo "žonglirati" sa njima.

P.S. - Win8 ima genijalan memory management. VS2013, SMSS, virtualka sa XPom i Firefox sa 20ak tabova. Samo 4GB RAMa a radi kao zmaj!

Fragmentiran je iz samog starta kad se moduli linkaju u kernel, tj blok u kom je kernel

Jesi siguran ?

Kernel se moze saltati po adresama, kad ga budes kompajlirao vidit ces da i to mozes konfiguirati iako sumnjam da genericne distibucije to koriste ali sigurno su izgradjene sa podrskom za to.

P.S. - Win8 ima genijalan memory management. VS2013, SMSS, virtualka sa XPom i Firefox sa 20ak tabova. Samo 4GB RAMa a radi kao zmaj!

Onda bjezi iz teme u windows.

Ne tjeraj me da pokrenem virtualku i 20tabova u firefox na manje od 2 Gb rama od cega je 1 dodjeljeno virtualki

Čak i shvaćam što je pjesnik ovdje htio reći. Da, učitavanje shared objecta, vanjskih kernel modula. Oni ostaju uvijek na istom adresnom prostoru dok god je system up jer inače ne bi radilo ništa. Isto kao i u windowsima sa dll-ovim. Istina. Ali to neće sprječiti niti tvoj super custom kernel ako počinješ dodavati aplikacije, module, library-e nakon kompilacije i instalacije. Taj problem nikada neće nestati zbog prirode samog OS-a i kernela, ali to je tako zanemarivo danas kada imamo gigabajte memorije, da ti kilobajti/megabajti ništa ne znače.

p.s. Slušaj kolegu Rust-a, ima više iskustva i znanja u tom području nego ti.

Ne govorim o modulima i njihovom adresnom prostoru, jos ti nije jasno.

Govorim o samom kernelu i ring 0 koji se od samog starta nalaze i rade u fizickoj memoriji koja je fragmentirana.

(gledajte to kao da linux radi u fizickoj memoriji (ring 0), dok GNU radi u virtualnoj memoriju koju je mapirao linux za njega (ring 1+))

I to se, naravno, moze sprijeciti jer moduli su potrebni samo nubvima koji ne znaju ili ne zele kompajlirati si vlastiti kernel. Zato i postoje, da bi ti mogao kliknuti par puta i instalirati i da bi sve sto ukupcas proradilo out of the box, to nije problem linuxa nego genericnih distribucija.

Linux sam po sebi nema nikakvih problema sa fragmentacijom.

A koliko ta fragmentacija znaci za performanse, govori i cinjenica da postoje vec par godina projekti koji izmisljaju rijesenja da bi se to sredilo ali bez uspjeha. To se zove fragmentation penalty i jedan je od glavnih problema performansa genericnih kernela jer izuzetno je bitno za performanse (cak i stabilnost) cijelog boxa da memorija u kojoj radi ring 0 ostane sto bistrija, i nevezano sa trenutni kontekst: sto manje zauzeta

Kada odbacuješ čiste memorijske stranice efektivno ništa ne dobivaš, budući da ih sistem tretira kao da i ne postoje. Bilo koji kernel to radi. Jedina je razlika što tvoj "optimizirani" kernel to radi odmah, pa vidiš nižu brojku. "Neoptimizirani" kernel će ih po defaultu ostaviti pa zatim pobacati van u roku odmah čim neka aplikacija zatraži još memorije (uvijek prvo čiste stranice idu na panj). Dakle jedina je razlika KADA će se to dogoditi, ne kako, niti koliko će vremena biti potrebno da se te stranice pobacaju.

Prljave memorijske stranice (one sa podatcima), ne možeš samo tako odbacivati. Možeš ih samo seliti u neku drugu memoriju (swap datoteku recimo).

Memorijski gledano ništa nisi dobio. A to što se i dalje nakon toga pozivaš na htop brojke je pokazatelj da ne razumiješ sam koncept čistih i prljavih memorijskih stranica, i razlog zašto jedne možeš odbacivati a druge ne. Evo ti pa čitaj (3.1.2 Swapping).

memorijska stranica = komad memorije čija je veličina u bajtima rezultat potenciranja s bazom 2 (najčešće 4096 ili 8192, ovisno o sustavu), predstavlja osnovni i najmanji blok logičke organizacije memorije u sustavu virtualne memorije. Svakoj memorijskoj stranici je dodjeljena fizička memorijska adresa za što se brine VMM, a procesorov MMU je zadužen za dinamičko prevođenje iz virtualnih u fizičke adrese.

čista memorijska stranica = ona u koju aplikacija još nije ništa pisala

prljava memorijska stranica = ona u koju je aplikacija nešto zapisala (sadrži neke podatke, a ne nasumično smeće)

I nisam ništa "zaključio". Raditi straw man argument ne pridonosi kvaliteti rasprave.

Debug simboli sami po sebi:

• predstavljaju jako mali učinak na zauzeće memorije nekog procesa, sve da ti se i executable utrostruči u veličini, u prosjeku je to zanemarivo uzevši u obzir kako lako i brzo i najmanje (fizički) aplikacije mogu alocirati ogromne količine memorije, dakle ovisi od slučaja do slučaja. U jednom Firefoxu koji regularno može raditi sa gigabajtima, prisutnost debugging simbola predstavlja samo beznačajnu brojčicu povrh već ogromne alokacije memorije.
• se lako uklanjaju koristeći strip
• ne moraju nužno biti učitani u RAM sa ostatkom izvršne datoteke (nalaze se u vlastitom odjeljenju), a i kada jesu u pravilu brzo završe u swapu (ili ih se samo čita iz izvršne datoteke budući da je cijela datoteka memorijski mapirana). Odnosno prelako ih se odbacuje, vjerojatno druge najlakše odbacive stranice nakon čistih stranica.
• predstavljaju manji problem po perfomanse. Prisutnost debugging simbola implicira debug build, što implicira build bez ikakvih optimizacija. A odsutnost optimizacija predstavlja kudikamo veći problem od nešto memorije što su simboli pojeli.

Možemo mi i dalje o debug simbolima, tu sam domaći, pa da vidimo kako stojiš

To si naucio. Super

Ali moras jos puno uciti o OS-u (linuxu)

Reci mi koliko koristis linux i koju distribuciju ?

Osnovni image nije kernel, zar i to ne znas ?

To je samo kernel konfiguracija kompresirana u neki image format, dok je kernel sadrzaj koji se iz te slike dekompresira u memoriju, a taj sadrzaj i image slika nisu isto jer ti mozes obrisati svoj kernel image a sustav ce i dalje raditi jer mu nisi  mogao obrisati kernel u memoriji.

A moduli kojih u genericnim distribucijama ima brdo aktivnih svakim startom sustava rade fragment jer se razbacaju, kernel zbog toga usporava jer zamisljaj ti to kako hoces ali fizicki sve je to ista cjelina schedulerima i ostalim kernel operaterima koji vec nekako uspore operaciju koja se sastoji od stotine koraka jer 20 puta preskacu blokve u operacijama sa razbacanim ringom 0

Cijeli ring 0 je razbacan (fragmentiran) zbog toga sto su fragmentirane sve kernel operacije sa hardwareom iz razloga sto je sve sto se tice hardware-a u racunalu vecinom pokrenuto kao modul u neoptimiziranom bloku

Eto, sad si i naucio da osnovni image nema veze s jezgrom koja radi u memoriji pa ces morat pronaci drugi argument

uvjek se može još malo flamati optimizirati. Tako rade pravi majstori. Samo PC hitna služba sve rješava format C-om, kauboj je suprotnost.

A ne, ne, ne. Nećeš mi to prodavati. Znaš ti jako dobro da sam mislio na sadržaj istoga. Cjepidlačiš u nedostatku argumenata, i nije ti prvi put.

Jao! Ne znaš ni na koji način CPU dohvača instrukcije iz memorije i kako je programski kod poravnat u toj istoj memoriji, te kako se to sve uklapa u fizičku podjelu memorije na stranice i keš linije, količinu stupaca po retku memorije (logička organizacija memorijskog čipa), koliki su zapravo penali pri prelasku iz retka u redak u odnosu na čitanje iz istog retka...

Ali ono, "već nekako uspore", jel? Moja kristalna kugla kaže da mora nekako biti sporije, ne znam točno kako, ni koliko.

Već sam ti rekao koji je najveći problem fragmentiranosti adresnog prostora. A fragmentacija samog koda to zasigurno nije. Nemaš pojma koji je voodoo uopće pokušati ići slagati ikakav ne-trivijalni kod tako da ga read-ahead procesora uvijek dohvaća bez potrebe za "nasumičnim" skakanjem iz retka u redak. A kad već skačeš po redovima, onda stvarno nije bitno koliko su razmaknuti. Ti u biti zamišljaš nekakav linearni slijed izvršavanja programskog koda bez ikakvih skokova uokolo, eh kada bi to bilo tako...

A još se nisam dotakao ni hardverskih prekida, koji cijeli slijed izvršavanja programskog koda efektivno čine ne-determinističkim.

Što to zapravo znači fragmentirana operacija? Operacija podijeljena na više manjih. A to ti je, brat bratu, svaka imalo ne-trivijalnija funkcija u bilo kojem kodu ikada napisanom. Iz te perspektive je onda praktički svaka operacija fragmentirana, a to vjerojatno nije ono što si imao na umu.

Programski kod koji izvršava te operacije može biti adresno "fragmentiran" (iako je "porazbacan" vjerojatno bolji naziv, budući da tzv. fragmenti ne mogu nastajati na bilo kojem mjestu unutar koda), i to je ono na što ti misliš. Bilo kako bilo, cijela ova tvoja konstantacija je tamo negdje na razini "nepotrebnih instrukcija".