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 7817E44037; Wed, 15 May 2024 16:50:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE8524025C; Wed, 15 May 2024 16:50:26 +0200 (CEST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id A729E4021D for ; Wed, 15 May 2024 16:50:25 +0200 (CEST) Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2e67dc957b7so3527851fa.3 for ; Wed, 15 May 2024 07:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1715784625; x=1716389425; 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=fl8yP5xLiGR39qczXrF4eNUjXCHiLDiPq4+igUnE7+s=; b=aH6sbNv8q9Tcot1vslN8ErHpgvGz8ODYgooG5nHcHrK6LrupILioP12xfhrn83Vsws LK1ymaoDj9NqyGFXhyh3StvxZWPzEAddF/W4GJnRfDVZuEafWLM9ViNPBrRDKgN3Pun9 GgGzCpkIj3qIBVP+l3uo+pa1P08iclViWipk8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715784625; x=1716389425; 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=fl8yP5xLiGR39qczXrF4eNUjXCHiLDiPq4+igUnE7+s=; b=DbWxqIOpW1mMC8EiGrZrj9gKYWysxioZNJz7re1bXxeYTqiX/AmvQJFzPWbVPaIHhu PneP9W9IJJUxiFhCVArjwNWYpiwBlqnNgSq1xL2EfrfetCCHqTWRPHBqQ8ApD6MRDPY5 UySN5RarMQYwXFpJ6gnvtzGODqtG8+QdnLnE65vMFR4PaqrY/jPwPoRAabIXEaG6npkl TuS+0Sy6BJ6LBeOe4G+SeHG2O47s4Rnd0wrPiTZ01BAriXuaLZPF7W+FC0T8AXsUwH+z JcFex4UGO7eFtu1DhZoQ7T4qLmCn0oioMyNR7JR2KalXt2UIge2IqrX0DPSEn9e2Ed8v n/tw== X-Forwarded-Encrypted: i=1; AJvYcCXmJo5jS8u/fL3Z9Nx8RmcYR/o/PjYGW/3va1v35RRV+2CMyfo2NOyiDi6bCISpgClC5GrBXLVk3w582B4= X-Gm-Message-State: AOJu0YwEwDT0ulFfOoRTsCIsMXxbPisVElR0Ud9sb39rHcxMzY2yP2gl UtmRc42irdTlYmkgOTfObvoNUFFAu44zJjXSyWRfgj5yzT5WXupI8JTAOcmq0rVex4HrkiSV8w/ 76l9PR2flIK8rNb3YkLZQgkMdQ94ze3SuYHW8Pw== X-Google-Smtp-Source: AGHT+IEL697eLkRufx/SOoaxP9xLBYWwxj4frejUtBsJJMaV5mNDREvrchuVayfM75Ov4uB0vMZ9vFerccdUL6OlQsM= X-Received: by 2002:a2e:8e93:0:b0:2de:d4ef:47d8 with SMTP id 38308e7fff4ca-2e5204b9e24mr92739741fa.3.1715784624938; Wed, 15 May 2024 07:50:24 -0700 (PDT) MIME-Version: 1.0 References: <20240430184533.29247-4-npratte@iol.unh.edu> <20240507174430.29403-1-npratte@iol.unh.edu> In-Reply-To: From: Nicholas Pratte Date: Wed, 15 May 2024 10:50:13 -0400 Message-ID: Subject: Re: [PATCH v6 0/2] Methodology change for hugepage configuration To: =?UTF-8?Q?Juraj_Linke=C5=A1?= Cc: probb@iol.unh.edu, bruce.richardson@intel.com, Honnappa.Nagarahalli@arm.com, thomas@monjalon.net, jspewock@iol.unh.edu, yoan.picchi@foss.arm.com, mb@smartsharesystems.com, wathsala.vithanage@arm.com, paul.szczepanek@arm.com, dev@dpdk.org 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 >What's the difference between this version and v4? Version 5 was a response to your suggestions regarding the semantics of the hugepage variable names as it relates to countable or uncountable nouns. This patch, which was originally just a single patch, was expanded into a patch series since the variable changes suggested are sort of logically independent of the original patch; there were talks about potentially making this a separate patch entirely, but we agreed that a patch series for this change is appropriate. But, to answer a question that I think you are indirectly asking, I ran into some issues when sending out the latest version of this patch. While the latest version of this patch, version 6, was sent last week and does show up on patchwork, it seems like the emails never reached the mailing list for some (I just asked Patrick in the office and he cannot seem to find them). > "type": "object", > "description": "Optional hugepage configuration. If not specified, = hugepages won't be configured and DTS will use system configuration.", > "properties": { >- "amount": { >+ "quantity": { > "type": "integer", >- "description": "The amount of hugepages to configure. Hugepage = size will be the system default." >+ "description": "The number of hugepages to configure. Hugepage = size will be the system default." > }, > "force_first_numa": { > "type": "boolean", The only change that version 6 made is in reference to the suggestion that Bruce made in a separate thread; I changed the description text from "amount of" to "number of." Hopefully this answers your question. Again, I ran into some issues sending the latest version out for this patch On Mon, May 13, 2024 at 5:53=E2=80=AFAM Juraj Linke=C5=A1 wrote: > > What's the difference between this version and v4? > > On Tue, May 7, 2024 at 7:44=E2=80=AFPM Nicholas Pratte wrote: > > > > In order to prevent accidental misconfiguration of hugepages at runtime= , > > the following changes are made to only allow for configuration of 2MB > > hugepages within the DTS config.yaml. In the previous implementation, a > > default hugepage size was selected via the size listed in /proc/meminfo= . > > The problem with this implementation is that, assuming the end-user has > > made prior modifications to the system, /proc/meminfo may default to > > hugepage sizes that are not recommended to be configured at runtime > > (i.e. 1GB hugepages). This can lead to two problems: overallocation of > > hugepages (which may crash the remote host) configuration of hugepages > > sizes that are not recommended during runtime. In this new implementati= on, > > we stipulate that any runtime hugepage configuration size that is not 2= MB > > is considered an outlier. If the end-user would like to configure eithe= r > > 1GB hugepages or any unique hugepage size outside of 2MB, then they sho= uld > > make these configurations either at startup (in the case of 1GB hugepag= es) > > or runtime outside of DTS configuration (if a user would like hugepages > > that are not 2MB). In either case, the expectation is that, if wish to > > use hugepage sizes that are not 2MB, you will make these changes outsid= e > > and prior to the initialization of DTS. > > > > The end-user has two options: remove the option for hugepage > > configuration in the conf.yaml, or keep the option and specify the > > amount of 2MB hugepages desired. In the case of the former, then we ass= ume > > that hugepages are already configured prior to DTS initialization. In > > the latter case, the user must define the amount of 2MB hugepages to be > > configured at runtime. If the amount of 2MB hugepages requested exceeds > > the amount of 2MB hugepages already configured on the system, then the > > system will remount hugepages to cover the difference. If the amount of > > hugepages requested is either greater than or equal to the amount > > already configured on the system, then nothing is done. > > > > Nicholas Pratte (2): > > dts: Change hugepage runtime config to 2MB Exclusively > > dts: Change hugepage 'amount' to a different term > > > > doc/guides/tools/dts.rst | 6 ++++- > > dts/conf.yaml | 8 +++--- > > dts/framework/config/__init__.py | 8 +++--- > > dts/framework/config/conf_yaml_schema.json | 12 ++++----- > > dts/framework/config/types.py | 4 +-- > > dts/framework/testbed_model/linux_session.py | 28 +++++++++++--------- > > dts/framework/testbed_model/node.py | 4 ++- > > dts/framework/testbed_model/os_session.py | 7 ++++- > > 8 files changed, 45 insertions(+), 32 deletions(-) > > > > -- > > 2.44.0 > >