On 10-Jun-20 11:14 AM, Francesco wrote:
Hi Anatoly
Il giorno mer 10 giu 2020 alle ore 11:24 Burakov, Anatoly
<anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> ha scritto:
On 09-Jun-20 8:40 PM, Francesco wrote:
> Hi Anatoly,
>
> Thanks a lot for the detailed response!
> Good to know anyway there's a "fix" already done in 20.05... also
> because I'm not interested in supporting secondary processes or
having
> shared memory...
>
> Looking forward for the backports in stable branches then!
>
> Thanks!
> Francesco
>
Hi Francesco,
Just to be clear - the "fix" i'm talking about is not about using less
memory - it's about not including this memory in core dumps. The memory
amounts used will stay the same (i.e. you'll still see the ~256GB used
each time you run DPDK).
Ouch ok I see.
My issue is that I have tools that look at the health of my server and
will report this high VIRT memory usage as anomalous - I guess I will
have to work around them some way.
Thanks for the clarification
Francesco
Yep. Like i said earlier, this is a design decision. I understand that
not everyone wants or needs secondary process support, but we have to
have defaults that cover the most amount of use cases. Plus, it make
internals very complex if we had two different init (and runtime!) paths
for DPDK with and without secondary process support. So, there's little
that can be done about that, short of lowering that limit at compile
time. You can use the CONFIG_RTE_MAX_MEM_MB and similar options in the
DPDK config file, but if you got your DPDK from a distro, you're out of
luck, i'm afraid.
--
Thanks,
Anatoly
