From: Stephen Hemminger <stephen@networkplumber.org>
To: Don Wallwork <donw@xsightlabs.com>
Cc: dev@dpdk.org, fengchengwen@huawei.com, mb@smartsharesystems.com,
anatoly.burakov@intel.com, dmitry.kozliuk@gmail.com,
bruce.richardson@intel.com, Honnappa.Nagarahalli@arm.com,
nd@arm.com, haiyue.wang@intel.com
Subject: Re: [PATCH v4] eal: allow worker lcore stacks to be allocated from hugepage memory
Date: Tue, 17 May 2022 08:56:07 -0700 [thread overview]
Message-ID: <20220517085607.435e67fd@hermes.local> (raw)
In-Reply-To: <20220517153136.23128-1-donw@xsightlabs.com>
On Tue, 17 May 2022 11:31:36 -0400
Don Wallwork <donw@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@xsightlabs.com>
> Acked-by: Morten Brørup <mb@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.
next prev parent reply other threads:[~2022-05-17 15:56 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 14:10 [PATCH] " Don Wallwork
2022-05-03 6:10 ` Morten Brørup
2022-05-03 13:08 ` Wang, Haiyue
2022-05-03 19:46 ` Don Wallwork
2022-05-04 3:08 ` Wang, Haiyue
2022-05-13 17:58 ` [PATCH v2] " Don Wallwork
2022-05-13 21:38 ` Stephen Hemminger
2022-05-16 19:43 ` Don Wallwork
2022-05-13 21:41 ` Stephen Hemminger
2022-05-14 3:31 ` fengchengwen
2022-05-16 19:47 ` Don Wallwork
2022-05-17 6:28 ` Morten Brørup
2022-05-16 19:50 ` [PATCH v3] " Don Wallwork
2022-05-16 20:28 ` Stephen Hemminger
2022-05-16 20:29 ` Don Wallwork
2022-05-17 15:31 ` [PATCH v4] " Don Wallwork
2022-05-17 15:56 ` Stephen Hemminger [this message]
2022-05-18 14:10 ` Don Wallwork
2022-05-20 8:30 ` fengchengwen
2022-05-23 22:35 ` Kathleen Capella
2022-05-24 13:48 ` Don Wallwork
2022-05-24 14:40 ` Burakov, Anatoly
2022-05-24 19:38 ` Don Wallwork
2022-05-24 19:46 ` [PATCH v5] " Don Wallwork
2022-05-24 19:51 ` [PATCH v6] " Don Wallwork
2022-06-01 0:05 ` Kathleen Capella
2022-06-20 8:35 ` David Marchand
2022-06-21 10:37 ` Thomas Monjalon
2022-06-21 12:31 ` Don Wallwork
2022-06-21 14:42 ` Thomas Monjalon
2022-06-21 14:52 ` Don Wallwork
2022-06-21 15:00 ` Thomas Monjalon
2022-06-21 16:32 ` Honnappa Nagarahalli
2022-06-21 19:33 ` David Marchand
2022-06-23 11:21 ` [PATCH v7] " Don Wallwork
2022-06-23 20:32 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220517085607.435e67fd@hermes.local \
--to=stephen@networkplumber.org \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=donw@xsightlabs.com \
--cc=fengchengwen@huawei.com \
--cc=haiyue.wang@intel.com \
--cc=mb@smartsharesystems.com \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).