[RFC] eal: allow worker lcore stacks to be allocated from hugepage memory
Stephen Hemminger
stephen at networkplumber.org
Tue Apr 26 23:21:24 CEST 2022
On Tue, 26 Apr 2022 17:01:18 -0400
Don Wallwork <donw at xsightlabs.com> wrote:
> On 4/26/2022 10:58 AM, Stephen Hemminger wrote:
> > On Tue, 26 Apr 2022 08:19:59 -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.
> >>
> >> Platforms desiring to make use of this capability must enable the
> >> associated option flag and stack size settings in platform config
> >> files.
> >> ---
> >> lib/eal/linux/eal.c | 39 +++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 39 insertions(+)
> >>
> > Good idea but having a fixed size stack makes writing complex application
> > more difficult. Plus you lose the safety of guard pages.
>
> Thanks for the quick reply.
>
> The expectation is that use of this optional feature would be limited to
> cases where
> the performance gains justify the implications of these tradeoffs. For
> example, a specific
> data plane application may be okay with limited stack size and could be
> tested to ensure
> stack usage remains within limits.
>
> Also, since this applies only to worker threads, the main thread would
> not be impacted
> by this change.
>
>
I would prefer it as a runtime, not compile time option.
That way distributions could ship DPDK and application could opt in if it wanted.
More information about the dev
mailing list