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 65A06439AC for ; Tue, 23 Jan 2024 22:00:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D6B89402A3; Tue, 23 Jan 2024 22:00:27 +0100 (CET) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by mails.dpdk.org (Postfix) with ESMTP id 9C7524025D for ; Tue, 23 Jan 2024 22:00:26 +0100 (CET) Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2cda523725bso49590171fa.3 for ; Tue, 23 Jan 2024 13:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706043626; x=1706648426; darn=dpdk.org; 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=ikEiB3e/0E15I0Fgxa0SzOWvrFn4t62nZUF3oV+xClI=; b=iOvW0GXN1CyeX3YnovbcDSW4gyJkYs7LoeDe8U6Q07k48vNB7gJUCX+leeBO1y3mEu JaRSqZeM58pgschfNHGMm2h/YiFCDYjEie5bZ0u1rBsVfNoxHvVEy2YgsFDEKpKAoXYT B5vY1wK3+2Y206YfwdQii87zOuTHt45lwlO+OTaVw3OOClrasRcQX+kPri3tN4JvePKU PjMkw75aLiC+wFol5KKsykNkNOg3pa8J600PcVb/T6CvePEIkGnVy+MwcRJwHh9STJkt Tn5nMpBE2AuCQuWzw2YS5UjeECBELq7cjUQQntZ9dEGStwwoxiqOJiGnWzaoWZ3HF2dE 0/xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706043626; x=1706648426; 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=ikEiB3e/0E15I0Fgxa0SzOWvrFn4t62nZUF3oV+xClI=; b=ry6bqMpC+G+M+e9yfU4vc92JJcY6IO4/3+/b1PGruhJRrl7hg+v9OlXkrV43d45nOV HZ5Bzb34lN3QW79D2SscY+rY+XDbK5LtIPu5J7gYH1IKW6x4bY6t2mFPNztRPiYFEkO5 UJz16iqNZeoQpFj+ylKKsgJ0x0WdKyzJq/lZbHVG9K9N535apB5Hhhk/kh0802pi0J6w Kzxe4+zKnH/aGjnrhT6XNfMCGrYh/2ZmPKaOeFvcpJKGTS/hQ/QjL+bs0lFDY9Pjc3TK 9S3n3ZDNLdmhjfAupEYwLrgMbP5A93Oar2maD8h7Lkd5FNJb3kRDkOYl0kTCjj5Q4yUw RQmA== X-Gm-Message-State: AOJu0YyxbtsIS6ZWKW39hVLZ8ylWlFwG7qDHesN98UOOAc/vUsC9eLy/ IK/uqUei0xERhILu3BodmUVMJg+UedH/n/cWpQlX1XCHavnfmS9J X-Google-Smtp-Source: AGHT+IF8ltGIrtYB1Jv1tWQVQA1/in8nuCuI0dbmhXF2yuzl5CpQ83kQXifgelkSpT+guVbBkSgbBA== X-Received: by 2002:a2e:b889:0:b0:2cf:1c9c:a43b with SMTP id r9-20020a2eb889000000b002cf1c9ca43bmr160767ljp.18.1706043625620; Tue, 23 Jan 2024 13:00:25 -0800 (PST) Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id c18-20020a05651c015200b002cce6095241sm3641448ljd.62.2024.01.23.13.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 13:00:24 -0800 (PST) Date: Wed, 24 Jan 2024 00:00:23 +0300 From: Dmitry Kozlyuk To: Sudhakar Vajha Cc: "users@dpdk.org" Subject: Re: KASLR enabled in Linux Kernel Message-ID: <20240124000023.73dacba5@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: 7bit 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 Hi Sudhakar, 2024-01-22 09:58 (UTC+0000), Sudhakar Vajha: [...] > During SBC 6400 initialization, requesting the system to create 64 huge > pages of 1GB size. Are you using API, possibly via functions? What are the exact request parameters: size, alignment, flags? > DPDK is leaving a space for one segment in the memory segment list and try > to remap the huge pages into the rest of the segments in the memory segment > list. Can you please provide logs or debug prints to confirm this is what's happening? > Note: Why DPDK is leaving a space for a hole in a memory segment list? > > Basically, DPDK is leaving the space to know how many segments there are in > order to map all pages into one address space, and leave appropriate holes > between segments so that rte_malloc does not concatenate them into one big > segment. But in this case, all the 64 pages are belongs to one address > space and leaving space for a hole is not required. Note: you seem to use the term "address space" for what is called DPDK allocator element (struct malloc_elem). At the same time, rte_malloc doesn't have logic to leave holes, as one element is allowed to contain memory from pages that are not physically contiguous. There is logic like this with --legacy-mem EAL option (page ranges that are not pysically contiguous are mapped to virtual addresses that are not contiguous as well), but from you logs it seems that you are not using it. > The following are my queries: > > 1. Why the space is leaving in the memseg list? And what is the > significance of the hole? If indeed using memzones, the following might happen. Memzone is internally a regular element to the DPDK allocator. It consists of the requested amount of usable memory, plus a header of 128B (also a trailer when RTE_MALLOC_DEBUG is defined). It is thus impossible to have all 64 GB of memory as usable via DPDK, because some little part of it will be internally used for element headers. Much more space may be lost due to alignment. Maybe aligning multiple times when ASLR is enabled accumulates too much loss. > 2. Can I scale up the size of the memory segment list to greater than the 64? You have to rebuild DPDK with RTE_MAX_MEM_MB_PER_TYPE and RTE_MAX_MEM_MB_PER_LIST changed as needed.