On 4/26/2022 5:21 PM, Stephen Hemminger wrote:
On Tue, 26 Apr 2022 17:01:18 -0400
Don Wallwork <d...@xsightlabs.com> wrote:
On 4/26/2022 10:58 AM, Stephen Hemminger wrote:
On Tue, 26 Apr 2022 08:19:59 -0400
Don Wallwork <d...@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.
Good point.. I'll work on a v2 and will post that when it's ready.
