Bug 386
Summary: | Big spike in DPDK process VSZ since release 18.05.1 | ||
---|---|---|---|
Product: | DPDK | Reporter: | Siddarth (siddsr) |
Component: | core | Assignee: | Siddarth (siddsr) |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ajit.khaparde, anatoly.burakov |
Priority: | Normal | ||
Version: | 19.11 | ||
Target Milestone: | --- | ||
Hardware: | x86 | ||
OS: | Linux |
Description
Siddarth
2020-01-30 14:18:28 CET
This is "by design". In order to support dynamic memory allocation for secondary processes, we need to guarantee that the memory space we'll be allocating *into* is available at all times. This is why this memory is reserved at startup, and the amount of memory being reserved is pretty huge (and depends on your system configuration - the more page sizes and NUMA nodes you have, the bigger the reserved amount) because we don't know in advance how much memory an application would need during its lifetime. This is the price we have to pay to support multiprocess *and* dynamic memory scaling. I do have a patch in the works that makes that amount configurable, but it is not possible to avoid that entirely without seriously restructuring the memory subsystem and adding a yet-another path to its already overcomplicated inner workings, so i'm not sure how much is there to fix. Even my patch provides relatively little control over the allocation process, because the EAL command-line is already complex-enough and i don't want to add fifteen different options to tune the allocator behavior. (plus, it also creates a maintenance and support burden) The reason this didn't happen in 18.02 is because the 18.05 release was the first one to feature the new memory subsystem. Siddarth, Does the explanation by Anatoly clarify your understanding? Thanks |