[v5,0/2] Methodology change for hugepage configuration

  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 implementation,
we stipulate that any runtime hugepage configuration size that is not 2MB
is considered an outlier. If the end-user would like to configure either 
1GB hugepages or any unique hugepage size outside of 2MB, then they should 
make these configurations either at startup (in the case of 1GB hugepages) 
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 outside
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 assume
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(-)
  

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 implementation,
we stipulate that any runtime hugepage configuration size that is not 2MB
is considered an outlier. If the end-user would like to configure either
1GB hugepages or any unique hugepage size outside of 2MB, then they should
make these configurations either at startup (in the case of 1GB hugepages)
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 outside
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 assume
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(-)
  

Resending the patch and superseding the old one on patchwork. I
accidentally sent this patch series through some kind of container
instance.

On Tue, May 7, 2024 at 1:44 PM Nicholas Pratte <npratte@iol.unh.edu> 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 implementation,
> we stipulate that any runtime hugepage configuration size that is not 2MB
> is considered an outlier. If the end-user would like to configure either
> 1GB hugepages or any unique hugepage size outside of 2MB, then they should
> make these configurations either at startup (in the case of 1GB hugepages)
> 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 outside
> 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 assume
> 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
>
  

What's the difference between this version and v4?

On Tue, May 7, 2024 at 7:44 PM Nicholas Pratte <npratte@iol.unh.edu> 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 implementation,
> we stipulate that any runtime hugepage configuration size that is not 2MB
> is considered an outlier. If the end-user would like to configure either
> 1GB hugepages or any unique hugepage size outside of 2MB, then they should
> make these configurations either at startup (in the case of 1GB hugepages)
> 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 outside
> 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 assume
> 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
>
  

>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 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
>
> What's the difference between this version and v4?
>
> On Tue, May 7, 2024 at 7:44 PM Nicholas Pratte <npratte@iol.unh.edu> 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 implementation,
> > we stipulate that any runtime hugepage configuration size that is not 2MB
> > is considered an outlier. If the end-user would like to configure either
> > 1GB hugepages or any unique hugepage size outside of 2MB, then they should
> > make these configurations either at startup (in the case of 1GB hugepages)
> > 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 outside
> > 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 assume
> > 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
> >
  

On Wed, May 15, 2024 at 4:50 PM Nicholas Pratte <npratte@iol.unh.edu> wrote:
>
> >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.
>

Ah, ok. There were a lot of patches so that confused me.

> 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."
>

As you mentioned in the other thread, I also like changing it in all
instances (in code and conf.yaml).

> 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 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
> >
> > What's the difference between this version and v4?
> >
> > On Tue, May 7, 2024 at 7:44 PM Nicholas Pratte <npratte@iol.unh.edu> 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 implementation,
> > > we stipulate that any runtime hugepage configuration size that is not 2MB
> > > is considered an outlier. If the end-user would like to configure either
> > > 1GB hugepages or any unique hugepage size outside of 2MB, then they should
> > > make these configurations either at startup (in the case of 1GB hugepages)
> > > 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 outside
> > > 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 assume
> > > 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
> > >
  

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 implementation,
we stipulate that any runtime hugepage configuration size that is not 2MB
is considered an outlier. If the end-user would like to configure either
1GB hugepages or any unique hugepage size outside of 2MB, then they should
make these configurations either at startup (in the case of 1GB hugepages)
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 outside
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 assume
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                     | 14 +++++----
 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 | 30 +++++++++++---------
 dts/framework/testbed_model/node.py          |  4 ++-
 dts/framework/testbed_model/os_session.py    | 11 +++++--
 8 files changed, 52 insertions(+), 39 deletions(-)