[LSF/MM/BPF TOPIC] Policy Groups: Decoupling Behavioral Policy from Resource Containment

[LSF/MM/BPF TOPIC] Policy Groups: Decoupling Behavioral Policy from Resource Containment

[Chris Li]

Introduction

The current cgroup (control group) infrastructure in the Linux kernel
is designed primarily for managing and isolating system resources. It
utilizes a hierarchical structure to express containment
relationships, where a parent cgroup's limits must always be greater
than or equal to those of its children. While this model is effective
for partitioning CPU, memory, and I/O bandwidth, it imposes
significant limitations when managing behavioral policies that are not
strictly related to resource constraints.

Problem
The "containing relationship" of the cgroup hierarchy is not ideal for
policy decisions. For example, in the context of selecting swap
backends for a job, a system might need to select a swap device based
on speed requirements. Latency-sensitive jobs may require high-speed
swap-in capabilities, while other jobs may not.

If a child group needs to utilize a swap device that is not present or
configured in its parent, it violates the typical cgroup resource
containment principle. Hierarchical resource management requires
parent resource parent >= child resource, but policy decisions often
do not follow this additive logic.

Another example is that in phone usage case, we can have different
behavioral policies for apps running in the foreground versus the
background app. Those are not necessary resource limit constraints.

Proposal: Policy Groups
I propose the introduction of Policy Groups, a mechanism conceptually
distinct from cgroups. Policy Groups would focus on managing
behavioral policies rather than resource limitations and would not be
bound by the hierarchical containment rules of cgroups.

Key features of the proposal include:

* Decoupled Governance: Policy Groups can serve policy management
needs better than the resource-centric cgroup model.
* Flexible Grouping: In many cases, Policy Groups could mirror
existing cgroup process sets to simplify synchronization. In this
mode, they act as a separate namespace for controlling
non-resource-related policies.
* Independent Views: Ideally, Policy Groups should allow for a
different view of process sets that does not necessarily match the
existing cgroup hierarchy.
* Simplified Hierarchy: A single-level (flat) structure may be
sufficient for many policy management tasks, removing the need for
complex hierarchical overhead.
Discussion:
I would like to discuss the following at LSF/MM/BPF:

1) Use Cases: Beyond swap backend selection, what other kernel
behaviors are better managed as policies than as resource constraints?
2) Interaction with cgroups: How can we implement Policy Groups to
allow for both "mirrored" and "independent" process sets?
3) Hierarchy vs. Flat: Is a flat namespace sufficient for policy
management, or is there a valid case for policy inheritance?
4) Minimizing Overhead: How can policy-specific metadata be allocated
with minimal memory impact?

Chris