<div dir="ltr">Salut, Calin.<div><br></div><div>Din ce am citit pe net se pare ca AIO-ul e limitat de filesystem [0], iar partea de O_DIRECT</div><div>si aliniere am mai gasit-o explicata de un tip pe stackoverflow [1] (trebuie sa testez si eu)</div><div><br></div><div>Ma voi mai uita maine (azi) sa vad daca mai gasesc informatii interesante pe net, iar in continuare</div><div>voi specifica de ce cred ca se poate intampla asta.</div><div><br></div><div>O prima idee, ar fi faptul ca la multe operatii AIO s-ar putea umple coada de scriere pe</div><div>disc (daca ne referim strict la scriere), iar operatiile in plus sa fie trecute de IO scheduler in</div><div>coada abia dupa terminarea unui numar specific de operatii deja existente in coada.</div><div><br></div><div>De asemenea, problema poate tine si de modul in care se plimba acul pe disc, incercand</div><div>sa serveasca cat mai mult cereri existente in coada; sau de dimensiunea sectorului (se poate</div><div>sa vina de aici necesitatea unei alinieri?)</div><div><br></div><div>That's just my 2 cents; astept si o parere mai avizata :)</div><div><br></div><div><br></div><div>[0] <a href="http://blog.libtorrent.org/2012/10/asynchronous-disk-io/#poorqualityofimplementations">http://blog.libtorrent.org/2012/10/asynchronous-disk-io/#poorqualityofimplementations</a></div><div>(partea de Poor quality of implementation)</div><div>[1] <a href="http://stackoverflow.com/questions/34572559/asynchronous-io-io-submit-latency-in-ubuntu-linux">http://stackoverflow.com/questions/34572559/asynchronous-io-io-submit-latency-in-ubuntu-linux</a></div><div><br></div><div>Mersi fain,</div><div>George</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-15 22:55 GMT+03:00 Călin Cruceru <span dir="ltr"><<a href="mailto:so@cursuri.cs.pub.ro" target="_blank">so@cursuri.cs.pub.ro</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bună Laura,<br>
<span class=""><br>
2016-05-15 22:36 GMT+03:00 Laura Vasilescu <<a href="mailto:laura.vasilescu@cs.pub.ro">laura.vasilescu@cs.pub.ro</a>>:<br>
> Bună Călin,<br>
><br>
> Nu știu cum e exact implementat AIO-ul în kernel (I'll have a look<br>
> tomorrow morning), dar e posibil ca operațiile să ți se termine pentru<br>
> că ai deja fișierele în RAM. Flag-ul O_DIRECT dat la open obligă<br>
> citirile și scrierile să se facă direct din device și să facă bypass<br>
> la partea de caching a datelor.<br>
><br>
> Încearcă să rulezi următoarea comandă înainte de a rula experimentul:<br>
> echo 3 > /proc/sys/vm/drop_caches<br>
> (comanda îți golește cache-ul curent; din păcate nu se poate dezactiva<br>
> operația de caching, este un lucru pe care îl face sistemul de operare<br>
> no matter what)<br>
><br>
> Ideea e că sistemul de operare îți bufferează fișierele în RAM (poți<br>
> să rulezi comanda free și o să vezi ce porțiune din RAM-ul tău este<br>
> ocupată cu astfel de fișiere; field-ul 'cached').<br>
><br>
<br>
</span>Mă îndoiesc că poate fi cache-uit având în vedere că e vorba de<br>
scrieri, iar la fiecare rulare conținutul bufferului este generator<br>
random.<br>
<br>
Călin<br>
_______________________________________________<br>
<a href="http://ocw.cs.pub.ro/courses/so/info/lista-discutii" rel="noreferrer" target="_blank">http://ocw.cs.pub.ro/courses/so/info/lista-discutii</a></blockquote></div><br></div>