Gyorsabb Firefox indulás preloading-gal a nightly build-ekben

Címkék

A hírek szerint egy 20 soros patch-nek köszönhetően a Firefox 4 akár kétszer gyorsabban indul el Windows-on. Ugyanez az eredmény érhető el állítólag Linux-on egy holt egyszerű egy soros módosítással. A fejlesztők ezen elgondolások mentén elindulva egy, az összes támogatott platformon működő preloading megoldással álltak elő. A funkció a Firefox 7-ben bukkanhat fel. Aki tesztelni szeretné, annak a nigtly build-ekkel érdemes próbálkoznia. Az elindulási időket az about:startup kiterjesztéssel lehet monitorozni.

Hozzászólások


+  while (ReadFile(fd, buf, sizeof(buf), &dwBytesRead, NULL) && dwBytesRead == sizeof(buf))
+    /* Nothing */;

LOL? Ez olyan mintha végig catolnám a binárisait h fs cachebe kerüljön bele.

Egszerubb ha az egesz gepen csak firefoxot futtatsz, mert igy valoszinuleg bucsut inthetsz az esetleg mas fontos dolgoknak ami mar cachelve van. Yuppe

Mivel haltak mar meg negyfeszultsegtol az emberek, ezert tavel kone tartani oket a mobil telefonoktol is, mert abban is van feszultseg? (Lehet kis fesszel is olni biz. modokon)

Biztonsagi oveddel te is vegletes vagy.

Nagyon furcsallom egyes embereknek azt a hozzallasat akik szerint valamit meg kell valtoztatni mar azonnal, mert hallottak, hogy a szomszedjuk nagybatyanak a testverenek az unokaocse szerint veszelyes a kiscicakra nezve.
Foleg ha valtozas komplexitast novel, felvet kompatibilitasi problemakat, es egyes felhasznalaosok eseten JELENTOS teljesitmeny csokkenest.
Es elvarjak, hogy mindenki higyjen nekik, csak mert ok azt mondtak, aki nem hisz neki vagy mast mond, az meg felelotlen idiota...

Lehet hogy tenyleg kene mar egy ilyen kiscicakra veszelyes agat fentartani, ahol nincsen lelassitva es tulhizlalva minden...

Aztan meg megy a panaszkodas, hogy kernel bonyolulet lett, meg 20ns slower, meg maskep nez ki az API mint 10 eve , kb. ugyan azoktol a kiscica ovoktol is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nagyon furcsallom egyes embereknek azt a hozzallasat akik szerint valamit meg kell valtoztatni mar azonnal, mert hallottak, hogy a szomszedjuk nagybatyanak a testverenek az unokaocse szerint veszelyes a kiscicakra nezve.

Az meg van, hogy sok éve a Megasploit frameworkben (amely nem csak a script kiddiek kedvenc játékszere) a Linux vsyscall kihasználásának módszere a default?

Ahol pedig nem lehet brute forceolni (pl. mert nem újra forkoló daemont kell exploitálni, vagy csak védelem van ellene, akár okos signal handlerrel), ott ez egy remek lehetőség a oneshot exploitra. Úgyhogy biztos lehetne szép számmal találni példákat az első - téves - kérdésedre is.

Foleg ha valtozas komplexitast novel, felvet kompatibilitasi problemakat, es egyes felhasznalaosok eseten JELENTOS teljesitmeny csokkenest.

Hát persze okoska, sok éve van ellene védelem a PaX-ban és a kedvenc disztród is használja, úgyhogy gyorsan vetesd ki, nehogy belassuljon a turbogentood.

Kooperációval lehet előbbre jutni, nem konfrontációval

Ahogy a szálban is látszott PaX Team kooperálni próbált - hisz a saját patch készletében már sok éve megoldott probléma ez és most hajlandóság látszott a mainstreamben való javításra is -, de szokás szerint konfrontáció lett belőle, köszönhetően Linus PaXTeamnek írt "shut up" és "stupid" érveivel...

Ingo pedig beállt puli kutya módjára a gazi mellé miután látta, hogy az megint elfelejtette bevenni a gyógyszerét, holott ő is a probléma gyors megoldásában volt először érdekelt.

Kicsit lentebb azzal eteted a nepet, h a kooperacio az isten, anelkul semmi sem jo, majd mikor ebben a threadben kiderul az, h PaXTeam konstruktivan allt a kerdeshez, gyakorlatilag kesz megoldast kuldott a problema megoldasahoz es utana Linus szoszerint lehulyezte es elkuldte a francba akkor hirtelen at kell menni ovodaba ? Gyakorlatban a kooperacio azt jelentene, h el kell donteni kinek az apukaja erosebb ?

---
pontscho / fresh!mindworkz

Felesleges: a célzásodból enélkül is következik, hogy nem ez az 1 szál alakította ki a kapcsolatuk domináns jellegét

Természetesen nem, hisz már jópárszor alulmaradt Linus&Co azokban a szálakban, ahol security témakörben kellett volna érvelni.

Nincs is ezzel baj, nem kell, hogy mindenki értsen az IT biztonsághoz, te is elég jól eltrollkodsz itt anélkül, hogy bármilyen fogalmad lenne róla... ;)

Kezdesz kifogyni az IQ-ból, mint általában :-)))

Kemény szavak ezek attól, aki saját bevallása szerint se olvasta el a szálat, csak write-only módban irkál.

Szabad érdeklődnöm, hogy te hol dolgozol? (Ha akarod, privátban küldd el, de szeretnék látni egy olyan munkahelyet, ill. tudni, hogy ilyen létezik, ahol nem kell konfliktusokat felvállalni ahhoz, hogy normálisan dolgozhasson az ember.)
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Közvetlenebbült írt, nem közvetlenült.

De nem is érdekes a HW, elég hogy a lyukas video driverekben lévő sebezhetőségeket - amelyeket eddig csak local lehetett kihasználni - most szépen lehetővé teszi remote/client-side oldalról is, mivel semmiféle védelem nincs ez ellen a WebGL specifikációban.

Mi mást tehetne? LOL

Pl. hogy az új veszélyforrásokat először feltárja, megérti és elkerülésük érdekében rögzít a specifikációban módszereket, amelyekkel ellehet kerülni a driverekben lévő biztonsági hibák triviális kihasználását (mint ahogy teszi a Silverlight 3D wrapper is).

Így sem lesz tökéletes, de a jelenlegi _semminél_ jobb lenne, az biztos.

> az új veszélyforrásokat először feltárja, megérti és elkerülésük érdekében rögzít a specifikációban módszereket

Ez a "mindent mi magunk csinálunk; nem kooperálunk, mert nincs hiányunk semmiből" stratégia. Egy másik meg a "korán publikálunk, aki tud besegíthet; kooperálunk, mert erőforrás hiányosak vagyunk és/vagy mert így 'közösségi'" stratégia.

Önmagában egyik stratégia sem teljesen helytelen és persze nem is teljesen tökéletes.

Tőlem reménykedhetsz nyugodtan, engedélyezem :-)))

A félelmetesen ostoba logikád ellen érveltem(*), amelyben úgy próbáltad beállítani a WebGL-t, mintha még csak egy tervezőasztalon lévő kezdeményezés lenne csupán, miközben már az összes aktuális Firefox és Chrome verzióban implementálva és alapértelmezetten bekapcsolva van.

(*) ez az a dolog, amit még te sose csináltál

Teljesen igazad van abban, hogy ami eddig szinte csak local volt kihasznalhato az remote lesz, mert a driverek bugosak.

Nem a WebGL specifikacio a hibas azert mert szarok a driverek.

Az input megfelelo szuruse meg implementacios kerdes, semmi koze egy alltalans szabvanyhoz.

(Mar driverekenk illene ezt jol csinalni, de nem biztos hogy benchamrkokon javitana, egyesek szerint driver verzio novekedesvel romlo teljesitmeny a gonosz GPU gyartok muve, hogy akkarjal ujabb kartyat venni.. )

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem a WebGL specifikacio a hibas azert mert szarok a driverek

Ezt nem is állította senki. Arra hagyatkozni viszont, hogy majd a gyártók javítják, amikor évek óta köztudott biztonsági hibákat se javítanak hatalmas nagy álom.

Az input megfelelo szuruse meg implementacios kerdes

Tévedés, eleve olyan protokollt kell kidolgozni, amely nem enged direkt kommunikációt a felsőbb réteggel. Ez nem csak egy egyszerű input szűréses kérdés.

egyesek szerint driver verzio novekedesvel romlo teljesitmeny a gonosz GPU gyartok muve

-> és emiatt sem frissítenek video drivert (meg egyébként se szoktak az átlag userek, nincsenek is rákényszerítve) -> még ha javítanák a gyártók a hibákat, akkor is védetlen marad a felhasználók jórésze -> tehát nem abban kell reménykedni, hogy majd a driverek lassú javítgatása megoldja az egész problémakört

"Tévedés, eleve olyan protokollt kell kidolgozni, amely nem enged direkt kommunikációt a felsőbb réteggel. Ez nem csak egy egyszerű input szűréses kérdés."

- Protokoll az valami olyan ami arrol szol, hogy mi megy a droton, es hogy ebbol mi mit jelenet, mire mit illik/szabad valaszolni.
Semmi koze hozza, hogy kapott infoval mit kezd az adott implementicio.

- WebGL nem protokoll.

- WebGL olyan APIt mutat ami "veletlenul" nagyon hasonlit az OpenGL ES 2.0 -hoz, az hogy mogotte tenylegesen mi van , ahhoz nincs semmi koze. Lehet ,hogy pont az van, hogy kozvetlenul meghivja az egyezo nevu fuggvenyt az adott rendszeren levo nativ programok altal is hasznalt libGl -bol , az is lehet (erosen valloszinu), hogy nem. Majd a bongeszo iroi eldontik, mivel ez impementacios kerdes.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Nem gond, ha nem tudod mit jelent a szó, csak nézz inkább utána mielőtt írsz."

Wiki:"Az informatikában a protokoll egy egyezmény, vagy szabvány, amely leírja, hogy a hálózat résztvevői miképp tudnak egymással kommunikálni. Ez többnyire a kapcsolat felvételét, kommunikációt, adat továbbítást jelent."

Pontosan tudom, hogy van tagabb ertelmezese, vagy mondjuk az orvostudomanyba mire hasznaljak. De informatikaban csak erre.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Akkor pontosan tudnod kellene azt is - még ha hálózatra korlátozod az értelmezését -, hogy akkor se az implementációtól függ az hogy kell értelmezni a protokollt, vagy a parancskészletet.

Mint például, amikor egyértelműen definiálva van, hogy az évet négyjegyű számmal _kell_ ábrázolni, lásd SMTP esetén is (RFC 5321).

Persze te implementálhatod máshogy is, csak épp nem lesz szabványos.

Nem mellesleg az RFC-kben rendszerint külön ki is emelik, hogy, mi az ami "MUST" vagy "MUST NOT", vagy "SHOULD" és "SHOULD NOT" és mi az, ami "MAY" vagy "OPTIONAL"...

Az SMTP-nel maradva, az SMTP megmondja, hogy hogyan kuldj el/fogadj egy uzenetet. De arrol semmit nem mond, hogy mit kezdesz vele. Nem resze az pl. hogy az SMTP szervernek mailboxban kell tarolnia a levelet, vagy relacios adatbazisban, vagy ...
Sot azt sem mondja meg milyen headerjei lehetnek egy uzenetnek.

Az sem resze, hogy milyen algoritmussal dontod el, hogy fogadod -e az adott cimre erkezo levelet vagy sem. Nem resze, hogy hasznalasz -e specialis hardvert , vagy sem. Nem mondja ki hogy Ethernetet kell hasznalnod.. (bugos firmwarrel:) )

Nem mondja, hogy text/shell-script content-type-al jovo levelet , le kell futatni rootkent azonnal, vagy sem.

WebGL -nel sincs megmondva, hogy mit hasznalsz ahhoz, hogy a specifikacioban foglalt eredmeny keruljon a megfelelo helyre.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Tovább esett az IQ-d, már a magad nyitotta subthread-et sem tudod követni. Nem baj, segítek. Ott tartunk, hogy:

>>> akkor se az implementációtól függ az hogy kell értelmezni a protokollt, vagy a parancskészletet.

>> ha az "év" == 3217, akkor implementálhatom, hogy kivágom a francba?

> [implicit igen]

Helyes; tehát mégiscsak "az implementációtól függ ...". [ Láttunk már olyan kódot, ami tele volt if-ekkel az ilyen-olyan implementációk "egyedi" értelmezései miatt ... ]

Tovább esett az IQ-d

Ugyan nem lenne elképzelhetetlen, hogy a veled való társalgás során az ember IQ-ja rohamosan esik (a sajátod saját magadtól nem tud az abszolút nulláról), de szerencsére csupán te beszélsz össze-vissza. Viszont a bohócoktól ezt megszoktuk, úgyhogy hajrá tovább zambojimiz! :)))

A Chrome-os blogger pont ezt hozta fel, hogy mindegy, hogy hogy szűröd az inputot, ahoz, hogy valami hasznosat tudj csinálni a GPU-val, muszáj megengedni potenciális, akár a drivert fagyasztó műveleteket (pl. valami jó bonyolult poligon számítást). Vagy be kéne tenni a szabványba, hogy mondjuk csak 10000 objektumot lehet létrehozni?
Meg inkább DOS-ról beszélt, nem exploitról (mint a te screenshotodon is).
Na szóval én nem vagyok egy grafikai programozó, úgyhogy ezekkel az érvekkel én nem vitatkozom. Persze szar, hogy ezentúl egy weboldal miatt kifagy a videokártyád...Na de most egy szar flash miatt is használhatatlanul be tud lassulni a gép. Lesz itt még webglblocker...

mindegy, hogy hogy szűröd az inputot, ahoz, hogy valami hasznosat tudj csinálni a GPU-val, muszáj megengedni potenciális, akár a drivert fagyasztó műveleteket (pl. valami jó bonyolult poligon számítást)

Szerintem ha egy driver le tud fagyni, akkor az eleve nem normális működés. A leterhelt RAID vezérlőtől se fagy meg a drivere... vagy ha igen, akkor az se normális dolog.

Vagy be kéne tenni a szabványba, hogy mondjuk csak 10000 objektumot lehet létrehozni?

Nyilván nem, hisz különböző videokártyák különböző teljesítményre képesek.

Meg inkább DOS-ról beszélt, nem exploitról (mint a te screenshotodon is).

Nyilván DoS-t egyszerűbb előidézni, de a probléma ott van, hogy kódvégrehajtást elérni se lehetetlen és itt közvetlen kernel címtérben való natív kódfuttatásról beszélünk, ahol nem játszik a böngésző biztonsága, a sandbox védelme, vagy akár magának a futtató felhasználónak a korlátozása/jogosultságai. A kernelben futó kód bármit megtehet alapból. Ezért is dolgozik már évek óta PaX Team pl. a kernel self-protection témakörén. A PaX-on kívül viszont sehol máshol nincsenek olyan jellegű védelmek, amelyek a kernelben és driverekben található biztonsági hibák kihasználását nehezítenék meg, vagy bizonyos támadási formákat kompletten ellehetetlenítenének.

Persze szar, hogy ezentúl egy weboldal miatt kifagy a videokártyád...Na de most egy szar flash miatt is használhatatlanul be tud lassulni a gép.

Ha kifagy az lesz a jobbik eset. Másrészről az se mindegy, hogy kifagy a rendszer, vagy csak belassul...

Régebbi ATI videokártyával és driverrel kékhalált is sikerült előidéznem. Szerintem pár éven belül lesznek WebGL/video driver exploitok már szép számmal, ha nem változtatnak drasztikusan a gyártók a jelenlegi helyzeten (amit viszont kétlek, mert a videokártya driver gyártókat nem érdekli ez a probléma).

Találtak és használtak már ki biztonsági hibát ethernet és wifi driverekben is (meg persze video driverekben is, de jobbára csak lokálisan).

A különbség az, hogy hálózati drivereknél jobban kiderülnek ezek a problémák (hálózati stressz tesztelés, fuzzing által pl.), jobban oda is figyelnek a fejlesztők az ilyen jellegű hibákra, mint a video drivernél, ahol eddig nem nagyon számított a biztonság. Ráadásul egy video drivernek nagyságrendekkel nagyobb és bonyolultabb kódbázisa van, mint egy hálózati drivernek.


Szerintem ha egy driver le tud fagyni, akkor az eleve nem normális működés. A leterhelt RAID vezérlőtől se fagy meg a drivere... vagy ha igen, akkor az se normális dolog.

Igazából nem is a drájver fagy, hanem a GPU...azzal, hogy ráküldenek egy olyan számítást, ami alatt az nem tud mást csinálni (desktopot se tud rajzolni közben). És itt jön az, hogy a driver meg lelövi a túl sokáig futó műveletet, és jön az ominózus üzenet. Persze ez baromira idegesítő, de a jelenlegi hardverek ezt tudják. Mellesleg ez a memóriával is előfordul, ott jön az OOM killer, CPU-val is, na ott meg a reset gomb.


Régebbi ATI videokártyával és driverrel kékhalált is sikerült előidéznem. Szerintem pár éven belül lesznek WebGL/video driver exploitok már szép számmal, ha nem változtatnak drasztikusan a gyártók a jelenlegi helyzeten (amit viszont kétlek, mert a videokártya driver gyártókat nem érdekli ez a probléma).

Ez akkor sem a WebGL hibája...A kékhalál videokártya miatt mindig is volt, sokaknál. WebGL nélkül.
De ezen, hogy milyen exploitokat lehet becsempészni, amit mondjuk a Silverlight-al nem lehet, nem tudok vitatkozni továbbra sem, lévén nem programozok egyikben sem.

Viszont ezzel azt is el tudom képzelni, hogy javul a driverek minősége idővel...most ugye letesztelik pár mainstream játékkal, ha azok elmennek, akkor jó. De hogy egyre általánosabban kezdik használni, kitesztelődik az összes code-path bennük...

Persze ez baromira idegesítő, de a jelenlegi hardverek ezt tudják.

Nem hiszem, ez színtiszta bénázás csak a mostani driverekben.

Mellesleg ez a memóriával is előfordul, ott jön az OOM killer

A memóriahasználat jól kontrollálható minden modern operációs rendszeren (setrlimit(2) ugye pl.).

CPU-val is, na ott meg a reset gomb

Már miért jönne a reset gomb? Te reszethez nyúlsz, ha valamelyik program elkezdi a CPU-t dolgoztatni?

Ez akkor sem a WebGL hibája...

Bah... senki nem mondta, hogy _ez_ a WebGL hibája.

.A kékhalál videokártya miatt mindig is volt, sokaknál. WebGL nélkül.

"Nincs itt semmi látnivaló, mindenki menjen szépen haza!"

milyen exploitokat lehet becsempészni, amit mondjuk a Silverlight-al nem lehet, nem tudok vitatkozni továbbra sem

Silverlight esetén van egy wrapper, ami egy layer és az beszélget a DirectX API-val, ami egy másik layer, mindkettőnél van ellenőrzés. A DirectX ráadásul szintén az MS kezében van és biztonsági szempontból is folyamatosan vizsgálják. A WebGL viszont közvetlenül a videokártya OpenGL interfacével beszélget (nincsenek meg azok a külön layerek, mint Silverlight+DirectX esetén), amelyik ráadásul nem a rendszer szállítójának a kezében van (MS), hanem a videokártya driver fejlesztőjének a kezében, aki magasról tesz a biztonságra, mert csak a minél jobb teljesítmény elérése a cél, másra nincs rákényszerítve.

Viszont ezzel azt is el tudom képzelni, hogy javul a driverek minősége idővel...

Idővel biztos, ha nagyobb nyomást fognak gyakorolni a video driver szállítókra. De ez egy tipikusan lassú folyamat.

De hogy egyre általánosabban kezdik használni, kitesztelődik az összes code-path bennük...

Van egy versenyhelyzet itt, amelyet a fuzzerekhez és debuggerekhez jobban értő exploit írók fognak inkább megnyerni, mint a fejlesztők.

Ráadásul a játékfejlesztőket szintén nem érdekli a biztonsági vonzata ezeknek a hibáknak. Nekik az a fontos, hogy a saját fejlesztésük haladjon. Kérdezz meg egy 3D engine programozót, hogy hány workaroundot kell beiktatni video driverek bugjai miatt. A hibák jórészét be se jelentik a gyártóknak, mert hajtás van, inkább valahogy megkerülik a problémát és haladnak tovább...

"A WebGL viszont közvetlenül a videokártya OpenGL interfacével beszélget"
Ha tobbszor leirod attol meg nem lesz feltetlen igaz.

"amelyik ráadásul nem a rendszer szállítójának a kezében van (MS), hanem a videokártya driver fejlesztőjének a kezében, aki magasról tesz a biztonságra, mert csak a minél jobb teljesítmény elérése a cél, másra nincs rákényszerítve."

A koztes layert a browserrrel egyutt lehet szallitani.
Netan ok is tesznek a biztonsagra ?

Az meg van -e, hogy az OpenGL ES 2.0 , eleve csak a reszhalmaza az OpenGL -nek? Megvan az is hogy az a resz konyebben implementalhato, es pl. regebbi OpenGL -ben levo unsafe dolgok nincsenek benne ?

DirectX -es backend reszt, olyan vendorok irjak akik nem tesztenk a biztonsagra, csak akkor ha OpenGL -rol van szo?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hmm, az ilyen "prefetch to cache" jellegu megoldasoknal mindig fura erzesem tamad. Ugyanez van ugye a "gyorsitsuk a boot folymatot" es egyeb esetben is. Ezt valahogy en mindig "csunya workaround" kategorianak tekintettem. Ilyen elven sokkal szebb lenne, ha be lenne vezetve egy uj syscall ami kb "cache hinting" lenne vagy hasonlo, es kozolne a kernellel, hogy a dolgok jelenlegi allasa szerint nagy biztonsaggal szukseg lesz az XYZ dolgokra. Aztan egy kernel thread (vagy akar user space cuccos is - foleg ha van info arrol pl user space fele kiexportalva) megnezne, hogy a cache-ben benne van-e mar, ha nem, akkor esetleg elkezdene beolvasgatni oda (esetleg kisse komplex dontesekkel, hogy megeri-e, miegymas). Akkor nem kene minden software, folyamat, whatever eseten "implementalni" ezt a feature-t, ami nem is biztos, hogy minden esetben optimalis raadasul (pl: keves a memoria mar amugy is, nincs is ertelme nagyon ennek akkor, ugyse nagyon fog cache-ben ottmaradni, ha nincs erre eleg memoria eppen: akkor csak felesleges I/O volt, ami adott esetben pont hogy lassit). Hasonloan gondoltam volna mint pl a madvise(), csak eppen itt meg egy nem feltetlen mmap-elt file-rol van szo, hanem csak a jovoben fog jonni. Vagy van ilyesmi, csak en nem tudok rola?

Windows ugyekben nem vagyok kepben, de errol olvastam mar regebben. Azonban az nem tiszta, hogy ez ilyen dinamikus dolog-e (egy applikacio kerheti-e tetszolegesen) vagy "beledrotozott dolog", es per app/eset alapon mindig ugyanugy tortenik. Ha ez utobbi, akkor lenyegeben nem sokkal tobb mint ezek a hack-ek amit a mozilla is csinalt (max kicsit szofisztikaltabb), de nem egy altalanos memory subsystem feature, ami rugalmasan igenyelheto.

+1

ez mekkora hülyeség (az indító téma).

ők is leimplementálnak valamit, aminek a rendszer oldalon kellene eldőlni. akkor már tényleg jobb lenne egy kernel space megoldás, ahol pl. a cache ürítésnél (vagy prefetch-nél) a döntést súlyozná az app-ok memóriában töltött idejük-, vagy kiosztott CPU idejük mértéke szerint, akár előzőkben gyűjtött statisztika szerint.

Én azt nem értem csak, hogy miért pont a 7-be (ugye most jelenik meg még csak az 5-ös)? Ilyen előre tervezett RoadMap van, hogy a startuppal kapcsolatos optimalizációk a 7-es verzióban lesznek?

Nálam a prefetch (Linux nem Firefox) tiltva van, mert ugye sokkal lassabb volt a boot-olás vele, mint nélküle.

Minden hónapban egyszer indítok OpenOffice.org-ot, de a marhája minden boot-nál prefetchelte, hogy nekem gyorsabb legyen. Szóval megvadultam és az egészet kivágtam a fenébe.

Persze lehet, hogy a mai prefetch már értelmesebb és figyelembe veszi a user szokásait is, de a legelső változattól az agyam eldobtam.

A legutolsó openSuSE-n persze nem érzem a hatását. Vagy letiltották, vagy a Molnár Ingo scheduler patch óta tényleg background megy az egész.

2011 a linux deskt 2 * 10^n soros csodapaccsok éve!

a grub-ba már bele kéne tenni, ez így szar.

Erossen /o\ megoldas.

----------------
Lvl86 Troll

[naive troll mode]
Akkor most már elindulás előtt is képes lesz megenni sok száz mega memóriát?
[/naive troll mode]

nem, a cache-re, van egy CPU 1 Mega L2 cache-sel, nehogyma' abbol 768kB ne lehessen a bugrokae! De majd a Firefox 7-hez mar 3 Mega cache-t fog enni a roka, igy mar a minimum kovetelmeny 4 Megas L2 cache-es processzorral valo rendelkezes lesz a Firefox 7 futtatasahoz!

Aztan jon majd meg tobb, az L1 cache-re vagyas a gyors indulasert, es minimum kovetelmeny lesz a 4 magos processzor, hogy a negyedikben meg maradjon hely a nemilyen modon tervezett programoknak :D

Meg hirtelen az a csunya jovokep is elem tarult, hogy 30 ev mulva: "mar egy 5 eves elavultnak szamitogepben is van 64 processzormag, mit zavar teged, hogy ezekbol 4-5 folyton vegetelen ciklusban fut es meg a cache-uket is elhasznaltatjak az osszeset a gonosz fejlesztok. Kulonben is most is arrol olvasod a hupot!!!!11!!!11 De optimalizalassal is max 10%-ot gyorsithatsz, tehat nem eri meg!!!"

(this comment is just kidding)

Komolyra forditva a szot: nekem boven eleg a RAM-ban, ki tudom varni azt a par masodpercet. Ha meg azt az IO miatt kell varnom alapbol (diszkrol fajlolvasas), akkor meg ennyi RAM mellett inkabb legyen egy rendes lehetosegem rendes copytoram-ra

Ez azt hiszem mindent elmond mindegyik tamogatott platform prefetchelserol...

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ez a modszer gyorsit a nem hasznalt/alig hasznalt rendszeren torteno inditast, es esetlegesen lenyegesen lassitja a hasznalt rendszeren torteno inditast.
Nalam ssd van /usr -re, nalam lassitana minden esetben.