Better supporting memory management in cgroup hierarchy

[zackliu]

Currently, the runtime finds the lowest memory limit in the hierarchy #93611 However, in the real cgroupv2 hierarchy, the memory management needs to be more complex.

For example, if the parent cgroup has a 1000MB memory limit and contains four subcgroups, each with a 500MB limit, the runtime should, of course, respect the 500MB limit of its own subcgroup. But if the total memory usage in the parent cgroup approaches 1000MB, the runtime should also recognize the low memory pressure at the parent level and trigger GC accordingly.

I think this can be abstracted as a common scenario: how to make the runtime aware of memory pressure from a larger environment. In the issue #93030 there're some proposals, and I think we need to proceed.

[Maoni0]

this means we actually had a problem when we added the hierarchy support? because GetCGroupMemoryLimitV2 would retrieve the smallest memory.max when it walks up the hierarchy, but GCToOSInterface::GetMemoryStatus would use just the current cgroup's physical memory load and divide it with a potentially much smaller limit that GetCGroupMemoryLimitV2 retrieved, instead of doing what GetCGroupMemoryLimitV2 does but with memory load, ie, walk up the hierarchy and retrieve the smallest memory load at each level. @janvorli, what do you think? of course this would mean walking the hierarchy every time we ask for memory load...

actually, looking at the code for GetCGroupMemoryLimitV2, does this account for the scenario where my process is running in a cgroup with memroy.max of 5GB, its parent cgroup has a memory.max of 3GB but does not enable memory in its subtree_control, shouldn't it get 5GB instead of 3GB? but this impl would get 3GB, right? since it does not check subtree_control.

[janvorli]

@Maoni0 let me refresh my memory on how the hierarchical limits work before answering the questions. It's been a while since I've made that change.
However, I think that for the last question, if the subtree_control disables memory then no child node can re-enable it. See:

Top-down Constraint¶
Resources are distributed top-down and a cgroup can further distribute a resource only if the resource has been distributed to it from the parent. This means that all non-root “cgroup.subtree_control” files can only contain controllers which are enabled in the parent’s “cgroup.subtree_control” file. A controller can be enabled only if the parent has the controller enabled and a controller can’t be disabled if one or more children have it enabled.

[janvorli]

doing what GetCGroupMemoryLimitV2 does but with memory load, ie, walk up the hierarchy and retrieve the smallest memory load at each level.

We would actually need to retrieve the largest memory load in the hierarchy, not the smallest, right? And yes, it seems it would make sense to do that to handle the scenario described by the issue.

[Maoni0]

We would actually need to retrieve the largest memory load in the hierarchy, not the smallest, right? And yes, it seems it would make sense to do that to handle the scenario described by the issue.

oops, of course by smallest I meant largest in this case😆

[zackliu]

Getting the load in the hierarchy seems the correct behavior. And in the container scenario, as there's cgroup namespace, the root cgroup that runtime can see is the container's cgroup. It's usually not too deep.