RE: [PATCH 8/9] dspbridge: add map support for big buffers

["Guzman Lugo, Fernando" <fernando.lugo@ti.com>]

>________________________________________
>From: Felipe Contreras [felipe.contreras@gmail.com]
>Sent: Thursday, August 26, 2010 5:04 AM
>To: Guzman Lugo, Fernando
>Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org; ohad@wizery.com; hiroshi.doyu@nokia.com; ameya.palande@nokia.com; >felipe.contreras@nokia.com
>Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers
>
>On Wed, Aug 25, 2010 at 10:42 PM, Guzman Lugo, Fernando
><fernando.lugo@ti.com> wrote:
>>> On Wed, Aug 25, 2010 at 7:00 PM, Guzman Lugo, Fernando
>>> <fernando.lugo@ti.com> wrote:
>>> >> Or the whole iovmm.c can be copied and just remove the mapping.
>>> >
>>> > That is the migration patches do, remove custom bridge
>>> mapping and use
>>> > iovmm module instead.
>>>
>>> You didn't get me; copy the iovmm.c code into dmm.c, and
>>> remove the mapping.
>>
>> It sounds like double work, changing the dmm.c which will disappear.
>
>But in the meantime the bug is still there, and there's no timeline
>when it will disappear.

I think you are talking about the issue when there are a lot of reservations and
unreservations of big buffer and the memory is getting fragmented and it is not
possible to allocate more big buffers.

if so, I don't think it is a bug. The thing is because of the algorithm used for 
reserve memory is optimized to satisfy the memory requested as soon as possible,
so this algorithm is good where there are too much reservation of memory and
for small buffers, because the algorithm get rid of big free chucks of memory
soon.

so that issue, can be fixed just chaning the algorithm without changing the array implementation
in dmm.c.

>
>> Also I think what you want is only the change from array to
>> Linked list.
>
>That's what I said.
>
>> Otherwise copying iovmm.c into dmm.c and adapting
>> To how dspbridge is at this momment it will need too much changes,
>
>Yeah, I just said that it was possible.
>
>> It is better to think like: take memory reservation (linked list)
>> Implementation from iovmm and map it to dmm.c.
>
>I think so too.
>
>> But I don't see the point of doing that, if dmm.c is about to
>> Dissapear.
>
>When exactly?

with iommu migration patches, hopefully next week.


Regards,
Fernando.

>
>--
>Felipe Contreras