running dpdk-procinfo or any secondary leading to system memory exhaustion

https://bugs.dpdk.org/show_bug.cgi?id=106

Bug ID: 106
Summary: running dpdk-procinfo or any secondary leading to
system memory exhaustion
Product: DPDK
Version: 18.05
Hardware: x86
OS: Linux
Status: CONFIRMED
Severity: critical
Priority: Normal
Component: core
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---

Issue: Running dpdk secondary instance in multiple iterations leads to memory exhaustion

Environment: Host & Virtual Machine

Primary App: DPDK l2fwd

Secondary App: simplified custom app

File:

Secondary:
int
main(int argc, char **argv)

{
        int ret;
        int i;
        char c_flag[] = "-c1";
        char n_flag[] = "-n4";
        char mp_flag[] = "--proc-type=secondary";
        char *argp[argc + 3];
        uint16_t nb_ports;

        argp[0] = argv[0];
        argp[1] = c_flag;
        argp[2] = n_flag;
        argp[3] = mp_flag;

        for (i = 1; i < argc; i++)
                argp[i + 3] = argv[i];

        argc += 3;

        ret = rte_eal_init(argc, argp);
        if (ret < 0) {
                ret = rte_eal_cleanup();
                if (ret)
                        printf("Error from rte_eal_cleanup(), %d\n", ret);

                rte_panic("Cannot init EAL\n");

}

        ret = rte_eal_cleanup();
        if (ret)
                printf("Error from rte_eal_cleanup(), %d\n", ret);

        fflush(stdout);
        fflush(stderr);
        return 0;
}

Run script:
#!/bin/sh

./build/app/test
ret=$?

while [ $ret -eq 0 ]
do
sync; echo 3 > /proc/sys/vm/drop_caches
./build/app/test
ret=$?
echo "ret ---------------- $ret"
done

You are receiving this mail because:
You are the assignee for the bug.

Exhaustion, meaning the kernel eventually - given enough iterations of the test program - invoke the OOM handler (i.e. crash)?

An application causing the kernel to cache more pages wouldn't normally be considered to be leaking memory, if those pages are not dirty. If "echo 3 > /proc/sys/vm/drop_caches" frees the memory "leaked", it wasn't leaked. That holds true even for system with swapping enabled.

You can't use MemFree (in /proc/meminfo) or similar as an indication how much memory is actually available to applications, would they need it. Pages that "echo 3 > /proc/sys/vm/drop_caches" frees, would also be free would the system come under memory pressure. A drop in MemAvailable is a better indication of applications' using more memory.

find $HOME -type f | xargs cat >/dev/null
For example, find+cat above aren't leaking memory, even if the pipeline likely causes MemFree to go down.

Anyway. If the answer to my first question is "the kernel crashes", you can ignore all this.

https://bugs.dpdk.org/show_bug.cgi?id=106

Vipin Varghese ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|IN_PROGRESS                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Vipin Varghese ([email protected]) --- Thanks Anatoly, this fixed tmpfs filling up. we ran this for almost 2 hours the memory is normal.

tested on x86_64 Linux platform

You are receiving this mail because:
You are the assignee for the bug.