TX2 SPI memory leak when modify spi clock rate

I use TX2, the bsp version is R32.3.1, I found memory leak when I modify spi clock rate. I use spidev test the test code like below. After test the Slab memory increase 2.5MB. I think there is something wrong with clock-tree subsystem. Please help me fix this issue, thanks.

#!/bin/bash
echo "before test"
cat /proc/meminfo | grep Slab
for((i=0;i<10000;i++))
do
   ./spidev_test.out -D /dev/spidev0.1 -s 2000000 -p "1111111111" # 2Mbps
   ./spidev_test.out -D /dev/spidev0.1 -s 10000000 -p "1111111111" // 10Mbps
    b=$(( $i % 100 ))
    if [ $b -eq 0 ]; then
        echo "while count: $i"
    fi
done
echo "after test"
cat /proc/meminfo | grep Slab

Does it loopback test?

Not loopback test.

Need any device connect to run this test?

No need connet deivce to run this test.

Can spidev_test run without problem without loopback or device?
Could you attached the spidev_test.out here

Yes, it run well no problem without loopback or deivce.
spidev_test.c (8.3 KB)
spidev_test.out (18.6 KB)

I don’t think there’s problem for it.
When I add sleep 10 after the for loop before the cat /proc/meminfo | grep Slab

before test
Slab:             142668 kB
while count: 0
while count: 100
while count: 200
while count: 300
while count: 400
while count: 500
while count: 600
while count: 700
while count: 800
while count: 900
after test
Slab:             143020 kB

Could you use this shell test?

#!/bin/bash
echo "before test"
cat /proc/meminfo | grep Slab
for((i=0;i<1000000;i++))
do
   ./spidev_test.out -D /dev/spidev0.1 -s 2000000 -p "1111111111"
   ./spidev_test.out -D /dev/spidev0.1 -s 10000000 -p "1111111111"
    b=$(( $i % 10000 ))
    if [ $b -eq 0 ]; then
        echo "while count: $i"
        cat /proc/meminfo | grep Slab
    fi
done
echo "after test"
cat /proc/meminfo | grep Slab

The test result is:

before test
Slab: 144968 kB
while count: 0
Slab: 144968 kB
while count: 10000
Slab: 147576 kB
while count: 20000
Slab: 150160 kB
while count: 30000
Slab: 153136 kB
while count: 40000
Slab: 155832 kB

Have some delay before to cat the Slab will show there is no Slab grew up.

before test
Slab: 143220 kB
while count: 0
Slab: 143220 kB
while count: 100
Slab: 143340 kB
while count: 200
Slab: 143200 kB
while count: 300
Slab: 143272 kB
while count: 400
Slab: 143284 kB
while count: 500
Slab: 143344 kB
while count: 600
Slab: 143432 kB
while count: 700
Slab: 143488 kB
while count: 800
Slab: 143432 kB
while count: 900
Slab: 143472 kB
after test
Slab: 143560 kB

The different is your test code loop count is small, could you use my last test code?

I don’t think this result can prove the memory leak.

I found that use two spi deivces and modify spi rate can lead to memory leaks. I modify spidev_test.c as attached . The test result as bleow

before test
Slab: 174104 kB
while count: 0
Slab: 174104 kB
while count: 10000
Slab: 176532 kB
while count: 20000
Slab: 179220 kB
while count: 30000
Slab: 181416 kB
while count: 40000
Slab: 184060 kB
while count: 50000
Slab: 186472 kB
while count: 60000
Slab: 189352 kB
while count: 70000
Slab: 192112 kB
while count: 80000
Slab: 194232 kB
while count: 90000
Slab: 197312 kB
while count: 100000
Slab: 199652 kB

spidev_test.c (8.3 KB)
spidev_test.out (18.6 KB)
spitest.sh (201 Bytes)

I don’t know the relation of memory leak with slab. Should check the memory leak by free -m?

Slab grew up beasue of kenerl call kmalloc() and not call kfree(). Pelease refer to this URL:
http://www.secretmango.com/jimb/Whitepapers/slabs/slab.html

Thanks for the info. However the SPI controller driver only allocate DMA buffer instead of kmalloc
Could you check if can reference to below like to get more informaiton.

I have found the memory leak beacuse of two device modify spi rate, so I think there is something wrong with the clock tree.

1 Like