imx53 video DMA memory fragmentation

[TimWoodham]

We use the analogue video input to display video on our screen on the imx53 standard platform which has a problem with displaying the video feed for an extended amount of time.  On average we're finding that after about 3 weeks of displaying the video feed on the screen we get DMA memory fragmentation.  The DMA memory fragmentation fragments so much that the video cannot start as it cannot allocate a contiguous memory block big enough and the video cannot be displayed.

The Linux kernel is 2.6.35.3 11_09 and we use the command to run the video

/unit_tests/mxc_v4l2_tvin.out -ow 450 -oh 600 -ol 550 -ot 1 -r 6 -f YU12

I've found the cat /proc/buddyinfo indicates that over time the free slots are 0's down to the size required to start the video

I've found that the memory compaction isn't available with this kernel release which is meant to re-order slots to fix the memory fragmentation issue that we're seeing.

The question is,

Has anyone found issues with displaying video for extended amounts of time on the imx53 linux 2.6.35.3 11_09 image. 

Has anyone found the need to get the compact the memory fragmentation which doesn't seem available as it doesn't compile in the 2.6.35 kernel.

Thanks in advance,

Tim

[Yuri]

Hello,

Below are considerations regarding the issue.

Usually SoC peripherals, allocate memory using dma_alloc_coherent() ;

this kernel function return contiguous memory area.

To preserve contiguous memory region :

    $ echo 1 > /proc/sys/vm/lowmem_reserve_ratio

Setting the parameter in this way, the Kernel will prevent application and file
caching to fragment “too much” memory. However it will limit the amount of
memory that applications can allocate.

For Dropping Caches :

     $ echo 3 > /proc/sys/vm/drop_caches

This will free all system caches, but this can impact other applications running
in the system, requiring them to load the files they use each time the caches

are dropped.

There are tools for avoiding file caching of a specific application like the
pagecache-management

https://code.google.com/p/pagecache-mangagement

This is an open source project not maintained and not supported by Freescale,
which could anyway help in the intent.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[TomE]

We've started getting this too.

In our case this is triggered by the video input being closed and opened at regular intervals (to display the image at a different scale). Every time this happens (on the "open()") the driver allocated a very large "dummy buffer" and four "screen buffers", all from contiguous DMA memory.

This is made worse by the TX53 continuously logging to a USB stick. These operations cache all the file data, and that's the main cause of the fragmentation. The suggestion of "drop_caches" fixes this problem, but causes stalls and other problems.

It fails trying to get the dummy buffer. There's a problem with the drivers in that they don't recover from this. Even if memory is freed up, the drivers won't work again until the unit is power cycled. That's a different bug.

There's a patch dated 2011 as "ENGR00159773-1" which caches the dummy buffer. There's a later patch "ENGR00169880" that allocates this buffer on the "probe()" rather than on the first "open()".

Applying these patches (if you have a later release, you should have these already) makes it last a little longer, but then it fails allocating the second of the four "Frame Buffers". There are no patches to cache these (but there should be).

The suggestion to "echo 1 > /proc/sys/vm/lowmem_reserve_ratio" does fix the problem in our case.