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

[vajk fekete]

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