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 097F842981; Tue, 18 Apr 2023 23:35:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7E2F44021F; Tue, 18 Apr 2023 23:35:35 +0200 (CEST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by mails.dpdk.org (Postfix) with ESMTP id CF1BD4014F for ; Tue, 18 Apr 2023 23:35:33 +0200 (CEST) Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2a8c30ac7e3so18323961fa.1 for ; Tue, 18 Apr 2023 14:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681853733; x=1684445733; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=lcpTgjevrpO0XF3HW39Dkp3T+JmApscYqv8bTKTPD4c=; b=jMHDORN47lJPJGZDSmMVWOshFTd9UiUjJW2IH8kgTVlaqrwspez/JbkcgwSP2AiOjw qKMJ2q079/tm4AD2xHO4bRq2WOxhF/QjjPrRTL2gNbF4B3fySq2Egdgv36lXQQX7qqoe cMLkxUQMvDrWv9cMgE4DPOnRXJgxKkOriCC3hJ15uj8s12a9upeMtARdYTUN9o/OP0Cq yMETN419Rm46sUrPhCZmk2NJ+GCjtSpvHl2CsD7MW8L3lhdA8SsSDag54IVEAIQmdia+ BNcMN8TqYCFSIH0qPJNogCqNIDPft+kFLVPHm7D/R6YdEkLbdpJIkjI8xxwX+EWt37ne BYBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681853733; x=1684445733; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lcpTgjevrpO0XF3HW39Dkp3T+JmApscYqv8bTKTPD4c=; b=P5sY4pHUbz7IkB4Ct8vcVsFLR6HccxW8Bx2VTkTAbJM9upkRhcLwwXG29ugrhPBXr2 swI+wyOo2WvRyOq6FwTFh2hr7B3tUDBJxBi3LJslEb78BMBsljaDjJFRry3JkPHslcN8 8r8x/K+NIiTVDhRt4hFe1MrgVwRUsdckTDK3pf+QLETey92ruhKf7k+7w8gpQkwVwOLf PxUkB3oWHxdVx6JfsRLHIlK5F8tvqsgrOYFBqtLfZ5DS5WFhf7YTBkglG1JUB+FIpQXr GmW1Pc5RkpeIYZkOZJYeBTYxRTvmqgDJ1i05CGL1XDzSqGfB+TnLNFJrmPlnRnRiTdSA 6Hrg== X-Gm-Message-State: AAQBX9e0a45grP6hPEvskN7ZlCmnyT2Lh0zQTRMkaieO+Vyvj7ZjzwzS EPM51ioSRj5dK+idcH92TdY= X-Google-Smtp-Source: AKy350auM4jm1dx4v+E3e2WSH1W8HG85tl3K39SHuDcb1LBAQNmRLCON4DU9ox2qIRhXHKoN6hHBFQ== X-Received: by 2002:a19:f70b:0:b0:4ed:cb37:7d95 with SMTP id z11-20020a19f70b000000b004edcb377d95mr1301883lfe.44.1681853733009; Tue, 18 Apr 2023 14:35:33 -0700 (PDT) Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id z14-20020a19f70e000000b004eb12850c40sm2481725lfe.14.2023.04.18.14.35.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 14:35:32 -0700 (PDT) Date: Wed, 19 Apr 2023 00:35:31 +0300 From: Dmitry Kozlyuk To: "wuchangsheng (C)" Cc: "anatoly.burakov@intel.com" , "dev@dpdk.org" , "jiangheng (G)" , "Yanan (Euler)" , "Suweifeng (Weifeng, EulerOS)" Subject: Re: [DPDK] heap memory fragmentation issue Message-ID: <20230419003531.6f492cce@sovereign> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Hi, 2023-04-12 08:44 (UTC+0000), wuchangsheng (C): > When using rte_malloc and rte_free to request and release memory repeated= ly, the usage of large pages gradually increases. Do you have a repro? > Checking the relevant source code shows that memory requests and releases > are started from the head of the freelist chain list of the heap. > Memory fragmentation seems to result from this, which is considered becau= se > the memory recently released may be in the cache, and requesting this > memory at the time of allocation may achieve higher performance? Could you please elaborate? DPDK uses "first fit" algorithm to select the free block, is that what you mean by "memory fragmentation seems to result from this"? > How does the community consider the heap's memory fragmentation issue? Is > there a future plan for memory fragmentation optimization? =46rom my experience with a production app, fragmentation is indeed an issue. Unfortunately, fragmentation often happens within a single 1G hugepage. It is impossible to coalesce free fragments of a hugepage into a contiguous block, like an OS would do with disjoint pages. Often the application can move its objects in memory, though. DPDK could provide means for applications to defragment memory this way. I don't think DPDK should drive the defragmentation process, because only the application knows when, which, and how much memory it is reasonable to move around. DPDK could provide facilities to analyze memory fragmentation degree (now possible by tracking objects and inspecting memseg, but hard) and to allocate memory at the desired range (API missing).