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 28EC34410E for ; Thu, 30 May 2024 12:29:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D7F9740A75; Thu, 30 May 2024 12:29:04 +0200 (CEST) Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by mails.dpdk.org (Postfix) with ESMTP id DA24D40691 for ; Thu, 30 May 2024 12:29:03 +0200 (CEST) Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-a62ef52e837so64943466b.3 for ; Thu, 30 May 2024 03:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717064943; x=1717669743; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9PAGrHpRZ+HMaeUhtu6kgbyZuQunz7tN17bIu43l7TM=; b=iU7M8wck3rxZl9MnKhGvOtExzA3DpRkjKQkwvkHZCOcPuD5gH/OOhJQf8LDJreInOI Tixv1vdL/nFEmV7lzALZasgJh00tLVpdrS9AY750PN9Cv594+YbYNuGwj9tvWOrXMwdH L3bULXv8d4KSYIGYMay2cHMizhCYcdgSWEEsuHqLr9JYKT+INVGpGnzAbMQO9Ve4jYkh bI/P/NiLrVW1wF4mTg524wyFfFgDoWvhppLc5c1bGJ/eDewO4v1BMFJpr64ZBLX73xXI zRWLyBuDL/mfa1iOnDbhOv4VBWMMMFMI8pM9aKmUJJkZQum6AHoR2UtDFBWqzR2mzVXt /kVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717064943; x=1717669743; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9PAGrHpRZ+HMaeUhtu6kgbyZuQunz7tN17bIu43l7TM=; b=qMIi7dDo+TeewXshFFbeV5Nc91wvv5WII/BVMMjP6TaJk9IUoO59WDVYRTxHfKos1y 1r3/7zFeZCiSys8bMIkm6O8UA1N8VkWAn6LOmu7M2LZzZqO+nhJCJKk1Zm1EAmwjkmWs EIVBut/XLwTxfP1X1LTmnrhP10Xw15RY8MqslIdDxK7pG2WW5AMKWRRFN4dxB/qL3h4B yD4W+0D00tTqQIxk9tp1Ac841YKX+cPMCCqh3V4L3Hram7bbeny+P98rPq0jrf9wGWsy 1Qfa/pK1HhIOO+MgMvxyALf9D0fwoyX1Lq1gMqFhPqIa43zY0qQ4t1zONaXA87vXZeTK lzaw== X-Gm-Message-State: AOJu0YyT5jpnPCy3LJFJimnhRzESz7cryH7AKc/GXW4a7PS4FtbBZNaY f26aBrzhFjI6JiVx4dv+iqA9SVrYbz/M2Rvy7ZJZNLMiD9kBXRnWV03v1gExbD6Ji8iA5mOwp3h mFeg2WQVNI5b73iz6gK59Ng85fQAqbBzB07U= X-Google-Smtp-Source: AGHT+IGi9GftWmlQnl9AM+R230MUQytF0JoQAGoD2tnNvcA/DenSxPAj+JpHmyrX/etjfKuvaFeNgzcvR6LQrLDW3LA= X-Received: by 2002:a17:906:7f01:b0:a62:821d:5df0 with SMTP id a640c23a62f3a-a65e8e406femr111170166b.26.1717064943130; Thu, 30 May 2024 03:29:03 -0700 (PDT) MIME-Version: 1.0 References: <20240510180743.53c37660@sovereign> In-Reply-To: From: Antonio Di Bacco Date: Thu, 30 May 2024 12:28:52 +0200 Message-ID: Subject: Re: Failure while allocating 1GB hugepages To: Dmitry Kozlyuk Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Just in case I need, let us say, 1.5 GB CONTIGUOUS memory zone, would it be fine to use something like this as GRUB config in Linux? default_hugepagesz=3D2G hugepagesz=3D2G hugepages=3D4" On Wed, May 22, 2024 at 12:22=E2=80=AFPM Antonio Di Bacco wrote: > > That was really useful. Thx > > On Fri, May 10, 2024 at 5:07=E2=80=AFPM Dmitry Kozlyuk wrote: > > > > 2024-05-10 11:33 (UTC+0200), Antonio Di Bacco: > > > I have 16 hugepages available per NUMA on a 4 NUMA system: > > > > > > [user@node-1 hugepages]$ cat > > > /sys/devices/system/node/*/hugepages/hugepages-1048576kB/free_hugepag= es > > > 16 > > > 16 > > > 16 > > > 16 > > > > > > Using the following program with dpdk 21.11, sometimes I can allocate > > > a few pages but most of the time I cannot. I tried also to remove > > > rtemap_* under /dev/hugepages. > > > rte_memzone_reserve_aligned is always supposed to use a new page? > > > > > > #include > > > #include > > > #include > > > > > > #include > > > #include > > > > > > int main(int argc, char **argv) > > > { > > > const struct rte_memzone *mz; > > > int ret; > > > printf("pid: %d\n", getpid()); > > > // Initialize EAL > > > ret =3D rte_eal_init(argc, argv); > > > if (ret < 0) { > > > fprintf(stderr, "Error with EAL initialization\n"); > > > return -1; > > > } > > > > > > for (int socket =3D 0; socket < 4; socket++) > > > { > > > for (int i =3D 0; i < 16; i++) > > > { > > > // Allocate memory using rte_memzone_reserve_aligned > > > char name[32]; > > > sprintf(name, "my_memzone%d-%d", i, socket); > > > mz =3D rte_memzone_reserve_aligned(name, 1ULL << 30, socket, > > > RTE_MEMZONE_IOVA_CONTIG, 1ULL << 30); > > > > > > if (mz =3D=3D NULL) { > > > printf("errno %s\n", rte_strerror(rte_errno)); > > > fprintf(stderr, "Memory allocation failed\n"); > > > rte_eal_cleanup(); > > > return -1; > > > } > > > > > > printf("Memory allocated with name %s at socket %d physical > > > address: %p, addr %p addr64 %lx size: %zu\n", name, mz->socket_id, > > > (mz->iova), mz->addr, mz->addr_64, mz->len); > > > } > > > } > > > > > > // Clean up EAL > > > rte_eal_cleanup(); > > > return 0; > > > } > > > > Hi Antonio, > > > > Does it succeed without RTE_MEMZONE_IOVA_CONTIG? > > If so, does your system/app have ASLR enabled? > > > > When memzone size is 1G and hugepage size is 1G, > > two hugepages are required: one for the requested amount of memory, > > and one for memory allocator element header, > > which does not fit into the same page obviously. > > I suspect that two allocated hugepages get non-continuous IOVA > > and that's why the function fails. > > There are no useful logs in EAL to check the suspicion, > > but you can hack elem_check_phys_contig() in malloc_elem.c.