Hugepage support for LCOW

[ninzavivek]

This adds hugepages support for LCOW.

A hugetlbfs drive can be mounted inside a LCOW. This is backed by a location in UVM. Currently, linux kernel shipped with containerd only supports hugepage size of 2M.

In order to specify a container path is a hugepage mount, hostpath needs to be specified as hugepages://2M.

In order for container to use hugepage successfully, it is expected UVM will be created appropriate KernelOptions annotation.

"io.microsoft.virtualmachine.lcow.kernelbootoptions" : "hugepagesz=2M hugepages=10"

UVM also has to be created with sufficient memory to host desired number of hugepages.

Ex:
"io.microsoft.virtualmachine.computetopology.memory.sizeinmb": "2048",
"io.microsoft.virtualmachine.lcow.kernelbootoptions" : "hugepagesz=2M hugepages=10"

In order to realize the performance of using hugepages inside the LCOW, memory backing the UVM has to ensured to use an approriate page size. The default page for physical memory backed UVM is 2MB. Hence, to ensure performance with using hugepage of size MB, UVM should be physcial memory backed.

"io.microsoft.virtualmachine.fullyphysicallybacked": "true"

Verification: Adhoc testing using updated containerd binaries/linux kernel /container image with a test app that tries to huge page.
Newly added functional test also passes.

[katiewasnothere]

Do you know if we have to set hugepagesz=2M if that's the default size for the kernel we're running? Just curious -- not an issue

[katiewasnothere]

I think we want to do something like:

"host_path": “hugepages://2mb/somepathname"

where sourcepathinuvm/hugepages/2mb is where hugetlbfs is mounted, and somepathname is a subpath under that mount. This will allow us to better control propagation between containers. Otherwise with the current route, every container that requests hugepages of size 2mb will see any files (but potentially not mountpoints depending on configuration) under the 2mb sandbox source path.

[ninzavivek]

Do you know if we have to set hugepagesz=2M if that's the default size for the kernel we're running? Just curious -- not an issue

I just did this to be explicit, so that in future if we add support for different pages at the same time, it is obvious, Let me know if you want me to remove it.

[ninzavivek]

I think we want to do something like:

"host_path": “hugepages://2mb/somepathname"

where sourcepathinuvm/hugepages/2mb is where hugetlbfs is mounted, and somepathname is a subpath under that mount. This will allow us to better control propagation between containers. Otherwise with the current route, every container that requests hugepages of size 2mb will see any files (but potentially not mountpoints depending on configuration) under the 2mb sandbox source path.

• Added a check in the CRI.

[dcantah]

Oddly enough some of the bridge gcs tests are failing here

[ninzavivek]

Oddly enough some of the bridge gcs tests are failing here

Kathryn, reran the tests, and they passed.

[ninzavivek]

Oddly enough some of the bridge gcs tests are failing here

They are passing now, after pulling in latest changes.

[dcantah]

This needs to get rebased to get Kathryns recent fixes

[ninzavivek]

This needs to get rebased to get Kathryns recent fixes

Done.

[dcantah]

As far as I can see this design follows what was discussed, lgtm. Just go related comments

[dcantah]

Still lgtm

[katiewasnothere]

lgtm