# Design Decisions - One cgroup per unconfigured task or a common cgroup for all unconfigured tasks

## Problem

If cgroup support is enabled in crinit and a task does not have a cgroup configured, in which cgroup should this process be placed?

## Considered Alternatives

### 1) Create a common cgroup for all unconfigured tasks

This common cgroup will get all tasks that do not have a cgroup configured in their task file.

*pros*
* The system can reserve specific resources for unconfigured tasks and there is no guesswork what would be a sensible default for a task specific cgroup

*cons*
* That common cgroup must be configurable in the series file
* Completely unrelated tasks start competing directly with each other in a more direct way than with no cgroups at all

### 2) Create a different cgroup for each unconfigured task

For each task that does not have its cgroup configured a new cgroup will be created before the process is started. The name could be generated from the e.g. the task name.

*pros*
* There is no direct competition to other unrelated tasks

*cons*
* It can be quite hard to guess sensible defaults for the resource available for that cgroup if it shall not be unrestricted.

### 3) Place the unconfigured tasks directly under the "real" root cgroup

The "real" root cgroup (that's the parent of the crinit created root cgroup) can have sub-cgroups and processes at the same time. Therefore it would be possible to have unconfigured tasks in that cgroup. That would be the default behaviour.

*pros*
* The least effort on crinit side

*cons*
* The unconfigured tasks would be quite high-ranked to compete for resources. That might get problematic in case of using crinit in a safety related context.

## Decision

Alternative 3 is taken.

### Rationale

### Open Points

None.