Cgroups

---

**Control groups **(or **cgroups **as they are commonly known) are a feature provided by the Linux kernel to manage, restrict, and audit groups of processes. It is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network, and so on) of a collection of processes.

In a Kubernetes environment, cgroups can be used to implement resource requests and limits and corresponding QoS classes at the pod level.

https://wiki.archlinux.org/title/Cgroups

Os cgroups são similares aos processos em:

• eles seguem uma hierarquia, e
• Os cgroups filhos herdam certos atributos de seus cgroups pais.

A diferença fundamental é que muitas hierarquias diferentes de cgroups podem existir simultaneamente em um sistema. Se o modelo de processo Linux é uma árvore única de processos, então o modelo cgroup é uma ou mais árvores desconectadas e separadas de tarefas (exemplo: processos).

Múltiplas hierarquias separadas de cgroups são necessárias porque cada hierarquia é anexada a um ou mais subsistemas. Um subsistema representa um recurso único, tal como tempo de CPU ou memória

CPU :          "Top cpuset"
                /       \
        CPUSet1         CPUSet2
           |               |
        (Professors)    (Students)
 
        In addition (system tasks) are attached to topcpuset (so
        that they can run anywhere) with a limit of 20%
 
Memory : Professors (50%), Students (30%), system (20%)
 
Disk : Professors (50%), Students (30%), system (20%)
 
Network : WWW browsing (20%), Network File System (60%), others (20%)
                        / \
        Professors (15%)  students (5%)

Control Groups extends the kernel as follows:

• Each task in the system has a reference-counted pointer to a css_set.
• A css_set contains a set of reference-counted pointers to cgroup_subsys_state objects, one for each cgroup subsystem registered in the system.
  • There is no direct link from a task to the cgroup of which it’s a member in each hierarchy, but this can be determined by following pointers through the cgroup_subsys_state objects.
  • This is because accessing the subsystem state is something that’s expected to happen frequently and in performance-critical code, whereas operations that require a task’s actual cgroup assignments (in particular, moving between cgroups) are less common.
  • A linked list runs through the cg_list field of each task_struct using the css_set, anchored at css_set->tasks.
• A cgroup hierarchy filesystem can be mounted for browsing and manipulation from user space.
• You can list all the tasks (by PID) attached to any cgroup.

The implementation of cgroups requires a few, simple hooks into the rest of the kernel, none in performance-critical paths:

• in init/main.c, to initialize the root cgroups and initial css_set at system boot.
• in fork and exit, to attach and detach a task from its css_set.

In addition, a new file system of type “cgroup” may be mounted, to enable browsing and modifying the cgroups presently known to the kernel.

https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cgroups.html

https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/

---

🌱 Back to Garden