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

[Andrew Lunn]

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.

	Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/