Linux distributes system resources using control groups (cgroup) which the kernel.org defines as

cgroup is a mechanism to organize processes hierarchically and distribute system resources along the hierarchy in a controlled and configurable manner. [1]

There are currently two versions of cgroup in use today and due to historical and compatibility reasons version 1 and version 2 of cgroups can coexist as long as there are no overlaps between which controllers are being managed.

The main, but not only, difference between cgroup version 1 and version 2 is that version 1 has a mount for each controller while version 2 unifies all the active controllers under a single mount point. This is obviously a very simplified explanation. Please see the official kernel documentation for more details on the two versions [2][3].

They typical mount point for both versions of cgroup is /sys/fs/cgroup. This is not a hard requirement and can be different depending on the distro. For instance Alpine Linux with OpenRC in hybrid mode will mount cgroup version 1 at /sys/fs/cgroup and version 2 at /sys/fs/cgroup/unified.

This table will assume that the cgroup root path is /sys/fs/cgroup and will use relative paths based on that. Adjust the relative paths based on your environment.

resource cgroup v1 cgroup v2
available memory ./memory/memory.limit_in_bytes ./memory.max
assigned cpu cores ./cpuset/cpuset.effective_cpus ./cpuset.effective.cpus
cpu bandwidth ./cpu/cpu.cfs_quota_us ./cpu.max
cpu period ./cpu/cpu.cfs_period_us ./cpu.max

Refer to the documentation for the format for each file.

To determine which cgroup your application belongs to you can reference /proc/self/cgroup which will list all the cgroup that your process belongs to. Depending on the environment you may also need to map your cgroup to the actual mount point by inspecting /proc/self/mountinfo. This is especially true if running inside a container where the cgroup may refer to the path on the host and may not be accurate when viewed inside the container.