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.
