[so2] [Tema3] OOM

[Irineu Barbieru]

2016-04-30 23:13 GMT+03:00 Razvan Deaconescu via so2 <so2 at cursuri.cs.pub.ro>
:

> Irineu Barbieru via so2 <so2 at cursuri.cs.pub.ro> writes:
> > Salut, asa cum se observa si pe vmchecker, procesul in cadrul caruia
> > ruleaza tema submisa de mine, e omorat. Ruland local, aceasta se intampla
> > intrucat, la testul 71, masina virtuala ramane fara memorie si se
> > blocheaza, din ce am reusit sa imi dau seama.
> > Totusi, ruland aceste teste, de la 71 la 78, separat, imi trec. Mai mult,
> > am verificat si cu ajutorul kmemleak si nu as avea leak-uri.
> >
> > Ar putea cineva sa se uite pe ea si sa imi dea vreun hint legat de ce
> anume
> > fac atat de gresit, incat sa ramana fara memorie? Eu mi-am tot batut
> capul
> > si nu am reusit sa imi dau seama.
>
> Salutare.
>
> Scuze de răspunsul tardiv, sărbători și toate cele.
>
> Din ce am urmărit codul sursă cred că problema este că ai prea multe
> zone "atomice" cuprinse între __bio_kmap_atomic și __bio_kunmap_atomic.
>
> Știu că ți-am zis că nu e nevoie de alocări de buffere, dar în soluția
> noastră de referință avem implementare cu buffere (alocate cu kmalloc)
> în care copiem datele din bio-uri pentru prelucrare. Nu avem niciodată
> mai mult de o mapare efectuată cu __bio_kmap/kunmap_atomic.
>
> Cred că în cazul tău nu rămâi fără memorie fizică ci fără spațiu pentru
> mapări temporare cu __bio_kmap/kunmap_atomic.
>
> Răzvan
> _______________________________________________
> http://ocw.cs.pub.ro/courses/so2/resurse/lista-discutii



Salut si Sarbatori Pascale fericite.

Ideea este in felul urmator: in urma discutiei de la laborator, am recurs
la varianta cu multe zone atomice, tocmai pentru a nu mai aloca buffere
locale(cu kmalloc). Inainte de asta, lucram pe modelul prezentat de tine,
cu buffere locale, in care copiam datele pentru prelucrare, si aveam
aceeasi problema.

In urma raspunsului tau, am modificat inca o data codul, aducandu-l intr-o
stare foarte asemanatoare cu ce aveam inainte de laborator, problema
manifestandu-se in continuare.

Probabil fac ceva prost, foarte greu de observat.

Irineu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so2/attachments/20160501/38d7ddf6/attachment.html>