Messages in this thread | | | Date | Wed, 23 Jan 2013 18:20:46 +0100 | From | Soeren Moch <> | Subject | Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls |
| |
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
| |