[core] Implement cgroup utils

[dentiny]

This PR implement IO operations to manipulate memory cgroup.

[rynewang]

so for this cgroup functionality we are not going to wrap it as a RuntimeEnvPlugin, instead we make a whole new set of abstractions? Do you have rationales for this?

[dentiny]

so for this cgroup functionality we are not going to wrap it as a RuntimeEnvPlugin, instead we make a whole new set of abstractions?

Yes. The process execution should have a few interception points which we could inject custom logic.
For example,

• before process starts (i.e. to prepare for runtime env);
• right after process starts, that should be where we get PID for the process, and place into the cgroup
• after process completes (i.e. to cleanup runtime env)

We only have (1) and (3), which are initialized at C++ side worker_pool.
At execution, we directly execute the binary inline with execve instead of a subprocess like subprocess.Popen, so we have another abstraction layer.

My planned way to implement cgroup related:

• Before execution (

  ray/python/ray/_private/workers/setup_worker.py

  Line 33 in e70b37a

  runtime_env_context.exec_worker(remaining_args, Language.Value(args.language))

  ), we apply cgroup changes
• Cleanup at C++ side worker pool, along with other resources

[rynewang]

for (2)

why don't we let setup_worker.py put itself into cgroup them exec?

[dentiny]

why don't we let setup_worker.py put itself into cgroup them exec?

Pseudocode looks like

runtime_env_context = RuntimeEnvContext.deserialize(args.serialized_runtime_env_context or "{}")

# My logic inserted before execution.
physical_context = GetPhysicalContext(runtime_env_context)
# Add current worker process into cgroup based on request.
SetCgroup(physical_context)

runtime_env_context.exec_worker(remaining_args, Language.Value(args.language))