[so2] [Tema3] OOM

[Irineu Barbieru]

2016-05-02 18:08 GMT+03:00 Razvan Deaconescu via so2 <so2 at cursuri.cs.pub.ro
>:
>
> Irineu Barbieru <irineu93 at gmail.com> writes:
> > 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.
> >
> > 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.
>
> Dă-i un submit pe vmchecker[1] să vedem codul. Sau dacă îl ai pe un
> repository privat (GitHub privat, GitLab, BitBucket), adaugă-ne și pe
> noi (echipa de asistenți) ca să putem vedea codul (eu sunt razvand sau
> razvan.deaconescu).
>
> [1] https://vmchecker.cs.pub.ro/ui/
>
> Răzvan
> _______________________________________________
> http://ocw.cs.pub.ro/courses/so2/resurse/lista-discutii

Am submis inca o data.

Mersi,
Irineu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so2/attachments/20160502/2d650b94/attachment.html>