Repository: kubernetes
Issue: The unit for hugepages is a page, not equivalent bytes of memory
Labels: sig/node,kind/feature,needs-triage

### What happened?

When dealing with hugepage resources, the unit of the resource is an entire page (typically either 2Mi or 1Gi sizes). The unit of the resource is not the amount of memory in bytes. Users of hugepage resources request X number of pages, not X amount of memory.

In our use of resource-topology-exporter and NUMA-aware scheduling plugins, we are seeing inaccurate reporting of hugepage resources. For instance, our compute worker nodes have 2 NUMA cells and each NUMA cell has 256Gi of RAM. Of that 256Gi RAM, we create 224 1Gi hugepages that we are able to allocate to workloads on the node.

Unfortunately, when we look at the amounts reported for each NUMA cell, we get this:

```
root@b37dev07c2mg01 [ ~ ]# kubectl get noderesourcetopologies/b37dev07c1co02 -ojsonpath='{.zones}' | jq
[
  {
    "costs": [
      {
        "name": "node-0",
        "value": 10
      },
      {
        "name": "node-1",
        "value": 20
      }
    ],
    "name": "node-0",
    "resources": [
      {
        "allocatable": "58",
        "available": "45",
        "capacity": "58",
        "name": "mellanox.com/mlnx_sriov_vfio"
      },
      {
        "allocatable": "52",
        "available": "44",
        "capacity": "56",
        "name": "cpu"
      },
      {
        "allocatable": "240518168576",
        "available": "201863462912",
        "capacity": "240518168576",
        "name": "hugepages-1Gi"
      },
      {
        "allocatable": "28606324736",
        "available": "25636757503",
        "capacity": "269661364224",
        "name": "memory"
      },
      {
        "allocatable": "6",
        "available": "6",
        "capacity": "6",
        "name": "mellanox.com/mlnx_sriov"
      }
    ],
    "type": "Node"
  },
  {
    "costs": [
      {
        "name": "node-0",
        "value": 20
      },
      {
        "name": "node-1",
        "value": 10
      }
    ],
    "name": "node-1",
    "resources": [
      {
        "allocatable": "6",
        "available": "6",
        "capacity": "6",
        "name": "mellanox.com/mlnx_sriov"
      },
      {
        "allocatable": "58",
        "available": "58",
        "capacity": "58",
        "name": "mellanox.com/mlnx_sriov_vfio"
      },
      {
        "allocatable": "52",
        "available": "52",
        "capacity": "56",
        "name": "cpu"
      },
      {
        "allocatable": "240518168576",
        "available": "240518168576",
        "capacity": "240518168576",
        "name": "hugepages-1Gi"
      },
      {
        "allocatable": "29461528576",
        "available": "29461528576",
        "capacity": "270516568064",
        "name": "memory"
      }
    ],
    "type": "Node"
  }
]
```

In resource-topology-exporter, they are [calculating the amount of hugepage resources](https://github.com/k8stopologyawareschedwg/resource-topology-exporter/blob/d641fcbb7548070041a1afdda4b87230d8661f72/pkg/sysinfo/sysinfo.go#L63
) by calculating the total amount of bytes that the sum number of pages represent.

They are doing so because upstream Kubernetes is using bytes as the unit instead of pages, and I'm not sure why upstream is doing that... hugepages should be treated more like indivisible CPUs that are allocated to a specific consumer and cannot be shared amongst multiple consumers. Making the unit of hugepages equal to the amount of memory a) makes hugepages look just like the memory resource (which is shareable across consumers) and b) is confusing to applications that consume hugepage resources since those applications typically request X number of hugepages, not Y amount of bytes.

### What did you expect to happen?

Treat hugepage resources as pages, not bytes of memory.

### How can we reproduce it (as minimally and precisely as possible)?

n/a

### Anything else we need to know?

_No response_

### Kubernetes version

All versions that support hugepages...


### Cloud provider

n/a

### OS version

Linux

### Install tools

_No response_

### Container runtime (CRI) and version (if applicable)

_No response_

### Related plugins (CNI, CSI, ...) and versions (if applicable)

_No response_