Caglar, The application should ensure clean up of DSPLink resources by calling the relevant CE shut down API's while stopping.
If you are you seeing a memory leak despite that, then we need to look into this further. Thanks and Regards, Deepali Uppal DSP/BIOS Link Platform Support Products -----Original Message----- From: Caglar Akyuz [mailto:[email protected]] Sent: Thursday, September 24, 2009 12:09 PM To: Uppal, Deepali Cc: davinci-linux-open-sou...@linux. Subject: Re: Dsplink Memory Leak Problem On Thursday 24 September 2009 09:34:48 Uppal, Deepali wrote: > Caglar, > > I need some more clarification before I can answer the questions that you > have asked. > > 1) Does your application ensure that all the DSPLink shut down API's like > MSGQ_close, POOL_close, etc are being called in the various components when > you stop your application? > > 2) Are you seeing memory leaks in your application despite calling all the > DSPLink shut down API's in all the components? > I'm using codec engine. I don't think there is much flexibility in this regard. > 3) Or is it the issue that since you have so many components in your > system, you cannot keep track of all resources that have been allocated in > your system. Since you cannot free the resources in a conventional way by > calling MSGQ_close etc you are looking for other alternatives? > It is exactly the 3rd. My platform(gstreamer) uses codec engine and AFAIK all the dsp start/stop actions occurs in one thread. However there is still some leak. So my best shot is playing with dsplink. Thanks, Caglar > Thanks and Regards, > Deepali Uppal > DSP/BIOS Link > Platform Support Products > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf > Of Caglar Akyuz Sent: Wednesday, September 23, 2009 6:05 PM > To: davinci-linux-open-sou...@linux. > Subject: Dsplink Memory Leak Problem > > Hi, > > I'm using dsplink 1.60 with latest git kernel. I noticed that dsplink leaks > some kernel memory during starting/stopping of a dsp application. I know > this is expected per [1] but this condition is hard to satisfy. Consider an > application consisting of dsplink + codec engine + dmai + gstreamer + some > gui library. I tried to satsify this condition on my application and fixed > all the known issues related to gstreamer-ti libraries. However, when I > continuesly start/stop my application dsplink leaks _kernel_ memory so I'm > forced to restart kernel at some point. This issue was also reported at > [2]. > > So I tried to track source of memory leak in dsplink. I modify MEM_Alloc > and MEM_free functions in mem.c. I keep a log of unfreed allocations in > dsplink. I export these information to userspace via sysfs interface. My > userspace application monitors sysfs file and notifies dsplink when all the > users are closed and dsplink kernel module frees those un-allocated > allocations. > > I have 2 questions: > > 1) Is there any way to know in dsplink kernel module that all dsp users are > shut down so that kernel module can free unfreed allocations without > userspace intervention? > > 2) What are the potential drawbacks of this solution. For instance, at > module load time dsplink performs 3 permanent allocations(*) so I keep > track of these allocations and do not free those areas. Is there any > possibility of more permament allocations during run time? > > Thanks, > Caglar > > (*) By permanent allocations I mean memory needed during whole dsplink > module life time. > > [1] > http://wiki.msp430.com/index.php/DSPLink_FAQs#Are_there_any_restrictions_on >_when_an_open_message_queue_can_be_closed.3F [2] > http://www.mail-archive.com/[email protected]/ >msg09949.html > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
