DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion
@ 2018-11-12 10:44 bugzilla
  2018-11-12 19:31 ` Mattias Rönnblom
  2018-11-13 17:03 ` bugzilla
  0 siblings, 2 replies; 3+ messages in thread
From: bugzilla @ 2018-11-12 10:44 UTC (permalink / raw)
  To: dev

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: dev@dpdk.org
          Reporter: vipin.varghese@intel.com
  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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion
  2018-11-12 10:44 [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion bugzilla
@ 2018-11-12 19:31 ` Mattias Rönnblom
  2018-11-13 17:03 ` bugzilla
  1 sibling, 0 replies; 3+ messages in thread
From: Mattias Rönnblom @ 2018-11-12 19:31 UTC (permalink / raw)
  To: bugzilla, dev; +Cc: vipin.varghese

On 2018-11-12 11:44, bugzilla@dpdk.org wrote:
> 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: dev@dpdk.org
>            Reporter: vipin.varghese@intel.com
>    Target Milestone: ---
> 
> Issue: Running dpdk secondary instance in multiple iterations leads to memory
> exhaustion
> 

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

> 
> 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
> 

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion
  2018-11-12 10:44 [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion bugzilla
  2018-11-12 19:31 ` Mattias Rönnblom
@ 2018-11-13 17:03 ` bugzilla
  1 sibling, 0 replies; 3+ messages in thread
From: bugzilla @ 2018-11-13 17:03 UTC (permalink / raw)
  To: dev

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

Vipin Varghese (vipin.varghese@intel.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|IN_PROGRESS                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Vipin Varghese (vipin.varghese@intel.com) ---
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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-11-13 17:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-12 10:44 [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion bugzilla
2018-11-12 19:31 ` Mattias Rönnblom
2018-11-13 17:03 ` bugzilla

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).