[elektro-etc] Mi a gubanc a PC-m sebessegevel?

[vajk fekete]

nekem ugy tunt, hogy egyszeruen az tortenik, hogy az ujonnan olvasott blokkot mindenaron be kell tegye memoriaba, es ehhez szabad memoriat kell csinaljon. es nem az 1000-el ezelotti blokkot fogja eldobni, mert annak a last accesse 10 masoperce volt, hanem azt a lapot, amin az egerdriver van, mert annak a last accesse 20 sec.

vajk


________________________________
From: Xorn <toth.endre at gmail.com>
To: elektro-etc at tesla.hu
Sent: Saturday, 13 August 2011, 7:10
Subject: Re: [elektro-etc] Mi a gubanc a PC-m sebessegevel?

A teljes szabad memoria lehet buffer kerdes nelkul, hiszen ez olyan
adat, ami nelkulozheto, azaz ha memoria kell valakinek, azonnal
eldobhato es allokalhato. Ezzel nincs gond. Gond meg magaval a
bufferelessel sincs, hiszen ugyis a memoriaban van az adat - csak at
kell adni a memorialapot a cache-nek es csinalni egy bejegyzest
valahol a cache leirojaban, hogy mi kerult oda. Ez nem egy nagy
tortenet, nem jelent tulsagosan nagy terhelest a rendszernek. A baj
ott kezdodik, ha az op.rendszer meg segiteni is akar, azaz az olvasas
hatasara elkezd barmilyen strategia szerint elore olvasni, olyasmit is
betolteni, amirol azt _gondolja_, hogy majd kelleni fog. Innentol
indul az eroforraspazarlas, es az ember meg leteszi a maradek hajat az
asztalra, olyan lassu lesz a cucc. Marpedig a vingyogy kulonlegesen
ismeretes arrol, hogy akkor is segit, ha bele doglesz is...

Best regards,
Andy

2011/8/12 vajk fekete <halaloszto at yahoo.co.uk>:
> azert ha belegondolsz, az elgondolas nem rossz. abban a retegben, ahol a buffert intezik, nem tudjak mi okozza a sok olvasast, csak hogy olvasas van. a problema valamilyen mertekig mas oprendszereken is fennall.
>
> lehet magas szinten kezelni: olyan masoloprogramot irni, ami megkeruli a buffert, mert tudja hogy szamara semmi ertelme. ha a totalcommander tenyleg tud ilyet, az nagyon klasz! (en nem hasznalom)
>
> lehet kezelni alacsony szinten is, pl korlatozni hogy a memoria max mekkora resze lehet buffer.
>
> vajk
>
>
> ________________________________
> From: Lőrincz Gábor <tucsi at madnet.sk>
> To: elektro-etc at tesla.hu
> Sent: Friday, 12 August 2011, 15:48
> Subject: Re: [elektro-etc] Mi a gubanc a PC-m sebessegevel?
>
> besza, ha ez tenyleg igy van akkor nagyon penge programozok dolgozhatnak
> Redmondban :(
>
> On 12.08.2011 14:29, vajk fekete wrote:
>> a windows io cachelese maig nem tud rola, hogy te fileot masolsz. csak azt latja, hogy olvasol mint allat, es probalja bufferelni, mert hatha megegyszer fogod olvasni ugyanazt, es akkor milyen fasza lesz hogy megvan memoriaban. ha elfogy a szabad memoria, mert mindet teliszarta a kessel, akkor korulnez, es a regen hasznalt blokkokat kikurja swapra, hogy legyen meg tobb hely kessnek. igy aztan mire atmasoltal 10Gbyteot, szepen mindenk ki lett turva a memoriabol, kb meg az eger driver is, ha nem nyultal az egerhez kozben. ha barmit akarnal csinalni, elobb vissza kell hozni diszkrol, csak ugye az pont nem nagyon megy, mert a diszknek sok a dolga...
>>
>>
>>
>> vajk
>>
>>
>> ________________________________
>> From: Xorn<toth.endre at gmail.com>
>> To: elektro-etc at tesla.hu
>> Sent: Friday, 12 August 2011, 12:25
>> Subject: Re: [elektro-etc] Mi a gubanc a PC-m sebessegevel?
>>
>> 2011/8/12 Kovács József<kj at faldeko.hu>:
>>> 2011.08.12. 11:24 keltezéssel, Xorn írta:
>>>> A disk I/O jellemzoen DMA. DMA alatt meg minden all, hiszen nincs
>>>> hozzaferes a memoriahoz, a CPU atadta a DMA vezerlonek. Ki kell varni,
>>>> azaz I/O-Wait allapotban van az egesz rendszer. Es mivel a lemez kb. 3
>>>> nagysagrenddel lassabb a memorianal, ez az eredmeny.
>>> Hmmm ... a DMA vezérlő egyik lényege éppen az, hogy
>>> ügyesen játsszon a címekkel és a busszal, lehetőleg
>>> kerülve  a procival való memória I/O ütközést közben...
>> Attol meg lehet szarul programozni felette a kernelt.
>>
>> A vingyogynak meg vannak olyan beesesei, hogy pl. elore olvasas es
>> read cache-eles, meg hogy akkor is hanyja kifele a memoriabol a
>> pagefile-ba a cuccokat, amikor van eleg memoria, hatha majd pont az
>> fog hianyozni valakinek valamikor stb. Ezekkel egyutt meg mar az
>> "ertekes" I/O is elegge bokan van rugva. Amugy meg elegge egyertelmuen
>> elmegy a kernelbe es kivarja az I/O-t. Ha a notebookomon sima SATA
>> HDD-vel csomagolok kifele egy RAR-t, akkor 30-40% a CPU kihasznalas,
>> mert egyszeruen nem jon tobb adat a lemezrol, es ennek is kb. a fele
>> "piros" a taskmanagerben, ha bekapcsolom a kernel ido kijelzeset.
>>
>> Amiota SSD van benne, az ilyen kicsomagolas folyamatos, full 100% CPU
>> kihasznalast eredmenyez abszolut ertekben alacsonyabb kernel ido
>> mellett! Gyorsabb az SSD, rovidebb az I/O wait, es megis dol az adat,
>> hogy mar a CPU lett a szuk keresztmetszet. Ennyi a nagy tortenet...
>>
>> Best regards,
>> Andy
>