Hi, fixed in r2070. hound starts at 335872B, Uses 528384B during playback, and falls back to 339968B during idle. I believe the one page difference between startup and idle is heap expansion, and should not be of concern.
regards, Jan On Mon, Feb 10, 2014 at 7:38 AM, Ján Veselý <[email protected]> wrote: > Hi, > > hound should not need dmamem_unmap_anonymous. The playback buffer does > not need to reside in DMA memory, that's driver's responsibility. > > You're right though, that it leaks the shared memory, it's due to > missing unmap call in release_buffer() (audio_device.c:375) > > Not sure how this ever worked, but generally there is around 200kB of > available DMA memory, that limits sb16 to 3 allocations before it runs > out of memory and hangs (waits endlessly in kernel). This forced me to > include ugly solution to dma_unmap, that was included in the original > merge. > It fixed the problem of 3 playback limit, so I'm not sure what memory > does the shared buffer occupy. > > I'll try to have a look at the other leaks, but probably won't have > much time until spring break (and there is the EHCI hw fail that I > need to squash too). My first guess would be that hound leaks client > received data. > > regards, > Jan > > On Mon, Feb 10, 2014 at 5:14 AM, Jakub Jermar <[email protected]> wrote: >> Hello, >> >> there seems to be a memory leak in the HelenOS sound daemon (hound). >> After fixing (sort of *) the missing dmamem_unmap_anonymous(), there >> still appear to be at least two leaks in this server. The symptoms can >> be seen by running e.g. top and playing a short .wav sample repeatedly >> using wavplay. As the sample is played over and over again, the amount >> of available memory will gradually decrease and the memory will not be >> returned back to the system unless hound is killed. This is what I have >> figured out so far: >> >> - hound for some reason does not destroy the shared anonymou DMA area, >> which results in 16 leaked pages (64 KiB) for each iteration (at least >> in the case of my .wav sample). >> >> - there must be yet another leak because each iteration consumes much >> more memory than those 64 KiB leaked in DMA memory >> >> Jakub >> >> * Now there is dmamem_unmap_anonymous(), but there is also a newly >> introduced race that makes it possible for the dmamem memory to leak in >> rare circumstances. I am trying to figure out how to get rid of this race. >> >> _______________________________________________ >> HelenOS-devel mailing list >> [email protected] >> http://lists.modry.cz/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
