[PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

[Soeren Moch]

On 23.01.2013 18:07, Soeren Moch wrote:
> On 23.01.2013 17:25, Andrew Lunn wrote:
>> On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
>>> On 19.01.2013 19:59, Andrew Lunn wrote:
>>>>> Please find attached a debug log generated with your patch.
>>>>>
>>>>> I used the sata disk and two em28xx dvb sticks, no other usb devices,
>>>>> no ethernet cable connected, tuners on saa716x-based card not used.
>>>>>
>>>>> What I can see in the log: a lot of coherent mappings from sata_mv
>>>>> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
>>>>> All coherent mappings are page aligned, some of them (from orion_ehci)
>>>>> are not really small (as claimed in __alloc_from_pool).
>>>>>
>>>>> I don't believe in a memory leak. When I restart vdr (the application
>>>>> utilizing the dvb sticks) then there is enough dma memory available
>>>>> again.
>>>>
>>>> Hi Soeren
>>>>
>>>> We should be able to rule out a leak. Mount debugfg and then:
>>>>
>>>> while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep
>>>> 60 ; done
>>>>
>>>> while you are capturing. See if the number goes down.
>>>>
>>>>        Andrew
>>>
>>> Now I built a kernel with debugfs enabled.
>>> It is not clear to me what I can see from the
>>> dma-api/num_free_entries output. After reboot (vdr running) I see
>>> decreasing numbers (3453 3452 3445 3430...), min_free_entries is
>>> lower (3390). Sometimes the output is constant for several minutes (
>>> 3396 3396 3396 3396 3396,...)
>>
>> We are interesting in the long term behavior. Does it gradually go
>> down? Or is it stable? If it goes down over time, its clearly a leak
>> somewhere.
>>
>
> Now (in the last hour) stable, occasionally lower numbers:
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
> 3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3394 3396 3396 3396 3396 3396 3396 3396
>
> Before the last pool exhaustion going down:
> 3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
> 3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
> 3247 3247 3247 3242 3236 3236
>
Here I stopped vdr (and so closed all dvb_demux devices), the number was 
remaining the same 3236, even after restart of vdr (and restart of 
streaming).

> Soeren