> -----Original Message----- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com > ] On Behalf Of Vladimir Pantelic > Sent: Sunday, May 24, 2009 10:52 AM > To: Troy Kisky > Cc: Koen Kooi; davinci-linux-open-source@linux.davincidsp.com > Subject: Re: SRAM allocator(s!) > > Troy Kisky wrote: > > Koen Kooi wrote: > >> On 23-05-09 01:15, Ring, Chris wrote: > >>> New thread, as requested... > >>> > >>> I like Rob/David's suggestion of adding calls to > >>> request_mem_region()/release_mem_region() in each allocator (SRAM > >>> and CMEM) > >> What's the plan for getting CMEM upstream? I've been asking that > >> question to TI engineers for a while now and the only responses > >> usually are "That's a good idea!" and "We don't know if it > will be accepted". > >> It shouldn't be too hard to get it pushed into Greg KH's > staging tree... > >> > >> regards, > >> > >> Koen > >> > > > > My personal bias is against CMEM being in the kernel. I > dislike pools > > of fixed size in an general purpose allocator. I think there are > > better ways to solve fragmentation problems. > > Actually, I do not understand why CMEM is always used with > all these "pools" and not with one big "heap", where any size > chunks can be allocated from. I am using a CMEM compatible > heap allocator with Davinci and OMAP3 for a couple of years > now and fragmentation never was a problem.
FYI, the insmod'er of CMEM can choose to have all pools and no heap, or all heap and no pools, or a mix of both. You may not experience fragmentation of the heap in your personal experience, but there is ample research that no heap-based allocator is immune to fragmentation issues, given the right (or wrong) set of allocation pattern. Having said that, CMEM is not really there to solve any fragmentation issue, it's there to provide physically-contiguous buffers of memory (original intent), and it has been exploited to allow user-mode programs access to general cache maintenance and virtual-to-physical translations of non-CMEM addresses. Regards, - Rob > > What I think should go into the kernel is a general (heap > based) allocator that can supply DSP/DMA mem in large > quantities, I agree it may not be CMEM with pools in the end. > > Regards, > > Vladimir > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
