From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AF2A7A0503; Tue, 17 May 2022 17:56:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6708740041; Tue, 17 May 2022 17:56:13 +0200 (CEST) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by mails.dpdk.org (Postfix) with ESMTP id 74ACC4003C for ; Tue, 17 May 2022 17:56:11 +0200 (CEST) Received: by mail-pg1-f178.google.com with SMTP id h186so14655415pgc.3 for ; Tue, 17 May 2022 08:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=h7ekn4pw+tijV2Ic/O7DyzePCWHLy97MvuGKEUcAEcA=; b=o61C7WpBGgHeEzVBZz3acoCxw75IGSrNTQMH8IxCIZAz8MTMdxpKiJMxC1KTCDlY2V MftrDd0dntv0SuefJ7A/wJeY3qc7Vyut9EAZZqCpF+8Q/j1AiEk61Un/buHX34ucuy+W HJ0n4iMPO62BdTFG917wy8bZ4tVC9Z7mHR/tt57zMsdd6a5M73ahMNGDw54hy6MGrw/A +bnJB0YNJSDnyxQzrngZ6TfRu54jaHH2t7LVgsDR21bTHn1lprHa58fiNE1tkBMIToYp naOsV1b8eVewJqW+YoHywaHtwgh1NqTwP1wavkug8cipgdKCSRvE6g3BdXkB9rmW07CK tK3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=h7ekn4pw+tijV2Ic/O7DyzePCWHLy97MvuGKEUcAEcA=; b=a+saL74SX9CSoUQDxRIpbTiz2Cd/8SXAIn9CjkNSTMb+ussWP4yGWFBuIZmtu0XbpW oew4wBaZQHaxSmlcXnZHi1ErTlzqPDtAJJeWSYMFCggY8mVin8W0FgDoEgjb504mlFCf BFpn5sWEEbSxjVDgJNNBoXVogI7yXvPexnYZ4oyDhdT0kw27/Ck66F31NSQvffJgLpXb R8V7YNZJ6uR9l6n/IczK5cKmtE8lDgXmKu3eSRuL10HLmCErsabbbcTYqqNy/QenmFeh bg7Rrvjfm+fYdYdR1yF5X4tFYJt91tX3CP9STkTsMPLXsQLwmJj9y4Ve56aP2aRU2smJ 1v7w== X-Gm-Message-State: AOAM5300JUWcJVlD58SfdvCk53+JLFAQ+c8usllppCLzxSeok5HBn/mP EXbuOjIrV33nkADgN4263Femxw== X-Google-Smtp-Source: ABdhPJwemKThR+HMNZZh8yrqgvN2mbpqF9fp1E/Xq0zeWwCHvLkDegsjyTjwgjikeN2Z/dAQArEJ5w== X-Received: by 2002:a65:43cc:0:b0:3c2:6d65:f1f0 with SMTP id n12-20020a6543cc000000b003c26d65f1f0mr19791414pgp.0.1652802970568; Tue, 17 May 2022 08:56:10 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id p3-20020a170902a40300b001618645a902sm3966546plq.155.2022.05.17.08.56.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 May 2022 08:56:10 -0700 (PDT) Date: Tue, 17 May 2022 08:56:07 -0700 From: Stephen Hemminger To: Don Wallwork 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 Message-ID: <20220517085607.435e67fd@hermes.local> In-Reply-To: <20220517153136.23128-1-donw@xsightlabs.com> References: <20220502141058.12707-1-donw@xsightlabs.com> <20220517153136.23128-1-donw@xsightlabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 17 May 2022 11:31:36 -0400 Don Wallwork 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. >=20 > 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. >=20 > Signed-off-by: Don Wallwork > Acked-by: Morten Br=C3=B8rup > --- 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.=20 Plus you could use eal_memalloc_seg_bulk.