[PATCH v4] eal: allow worker lcore stacks to be allocated from hugepage memory

[Don Wallwork]

On 5/17/2022 11:56 AM, Stephen Hemminger wrote:
> On Tue, 17 May 2022 11:31:36 -0400
> Don Wallwork <donw at xsightlabs.com> wrote:
>
>> Add support for using hugepages for worker lcore stack memory.  The
>> intent is to improve performance by reducing stack memory related TLB
>> misses and also by using memory local to the NUMA node of each lcore.
>>
>> EAL option '--huge-worker-stack [stack-size-in-kbytes]' is added to allow
>> the feature to be enabled at runtime.  If the size is not specified,
>> the system pthread stack size will be used.
>>
>> Signed-off-by: Don Wallwork <donw at xsightlabs.com>
>> Acked-by: Morten Brørup <mb at smartsharesystems.com>
>> ---
> This looks great, just thinking a little more about what the impact
> of using it would be.
>
> Since the memory region for the stack is never freed, it will cause
> complaints from address sanitizer and maybe from valgrind.
>
> One way to workaround that would be to use the lower level allocation
> routine to get the memory segments. This would make stacks a multiple
> of page size which would not be bad idea anyway.
> Plus you could use eal_memalloc_seg_bulk.
>
The problem with using this API is that it requires allocating page 
sized stacks
which would be undesirable in memory constrained environments or when the
huge page size is 1GB.

We looked for a place to free this memory, but could not find any place 
in DPDK
where the worker threads are canceled.  Obviously the worker threads 
have to
be stopped before we can free this memory.