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 B1DCF41C89 for ; Mon, 13 Feb 2023 15:59:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6444342D39; Mon, 13 Feb 2023 15:58:49 +0100 (CET) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by mails.dpdk.org (Postfix) with ESMTP id E018E40DDB for ; Wed, 8 Feb 2023 03:43:56 +0100 (CET) Received: by mail-wr1-f49.google.com with SMTP id g6so7416248wrv.1 for ; Tue, 07 Feb 2023 18:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=c1MBcn0CQF0paFZBZDXd7wxRF1P91j0nHZ1/lRvjIfw=; b=eWDjGluUXS49oVRIrk3nGDpqzMEK6ObryLFHqSe8jrLOcaNFkMgODMlfYub7V2U64O lR6w4h14c2FgbCH2mjfbG8Jq/xpxavMJ75RIBp2XqvS1mxbMW95aSOnzHWebPNWpHw6Q 5yRAbdAUW4//BNqN33JSQTrkoTXxPCBGdSUHnU4dw0zYcdLGxiPNPAz7oZRBntn19nv9 tP38uX0BNBYebyfg4FFaenJozvtqoVN4HlWy5GFpqHjfpAFulyugzlZAf3nGvsAqL+7s lCxybp+HBMw30Xfs3Xh0XslVr/IIBCGoTbEF0Bma4AZcV2d16Pvd1amK2S4HbXXVg7xX CJoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=c1MBcn0CQF0paFZBZDXd7wxRF1P91j0nHZ1/lRvjIfw=; b=aPopcYSGknVckGLEqVqI91yykezewP/OEMilo6vYMl35l1NNOTs00EthTA/MYClYBy yeBXup2Ajz5sdh9W3yJOzrqFp8ZELF5k31fGLk5X3PNYTZydjZZd+asQDyyQq2kW37IM qRpQtVoIKnIetXUAHA/tXintSsJ/l0glqJnOW43FIWniEALHjHiPr4tP1QjETvzuzinn VBRf407fTCUdhYRnhYT/buTt3D4+/UIJqadYw0FaMy4AG/9+t3gRPaLWF+3DU5zeOzGK y+4S3RpB6xscJgQdZ/UnF2uVaxwuIBrNRtee1zQ5YiazQCUazvKfms3BBcYWNGAubPUm Y1Ow== X-Gm-Message-State: AO0yUKUDOLcoBgT9JD1v9yd11HgIj9420fdFwftVwp0/T+ZfTxQTqzWx WypPIP1xZD9LjUbORE6SNbyf9AhRFs7lWG7WAViEENjCeK6XgA== X-Google-Smtp-Source: AK7set+sPKRwWclV/NEnXcsvO0vXC2hxXk8XnZPJLKLQERZSkZYCHYzjqyqKuEoTyuepFQR+TM7ODK92ZlydktnPzGU= X-Received: by 2002:a5d:6386:0:b0:2bf:d201:bfc6 with SMTP id p6-20020a5d6386000000b002bfd201bfc6mr144312wru.396.1675824236166; Tue, 07 Feb 2023 18:43:56 -0800 (PST) MIME-Version: 1.0 From: Szymon Szozda Date: Wed, 8 Feb 2023 03:43:45 +0100 Message-ID: Subject: Dpdk allocates more memory, than available physically (hugepages) To: users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000004d836d05f4273c8b" X-Mailman-Approved-At: Mon, 13 Feb 2023 15:58:47 +0100 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --0000000000004d836d05f4273c8b Content-Type: text/plain; charset="UTF-8" Hey, I'm running dpdk on a machine with 64GB of RAM. It is configured, so 16GiB (16 x 1GiB chunks) of hugepage memory is reserved on boot. I was expecting dpdk to consume only those 16GiB, but it seems it gets more than 30GiB of virtual memory ( I base it on memory VSZ output of top command ). The machine is 1 NUMA, 1 NIC. I did some debugging and I do not see any logic which limits the memory consumption, basically it seems that eal_dynmem_memseg_lists_init() will allocate the same amount, no matter how much RAM is physically available. Is it expected? How to know that setup will not crash due to insufficient memory available? How to limit those memory consumption.by dpdk? --0000000000004d836d05f4273c8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey,
I'm running dpdk on a machine with 64GB of RAM= . It is configured, so 16GiB (16 x 1GiB chunks) of hugepage memory is reser= ved on boot. I was expecting dpdk to consume only those 16GiB, but it seems= it gets more than 30GiB of virtual memory ( I base it on memory VSZ output= of top command ). The machine is 1 NUMA,=C2=A01 NIC. I did some debugging = and I do not see any logic which limits the memory consumption, basically i= t seems that eal_dynmem_memseg_lists_init() will allocate the same amount, = no matter how much RAM is physically available.

Is it expected? How = to know that setup will not crash due to insufficient=C2=A0memory available= ? How to limit those memory consumption.b= y dpdk?
--0000000000004d836d05f4273c8b--