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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,...)

  Soeren

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]