How IBM’s CPU Namespace Prototype Redefines Linux Resource Isolation

Linux Namespace Concept

Namespaces are a kernel mechanism that partitions global resources so that distinct groups of processes see different views of identifiers such as PID, hostname, UID, file names, and network/IPC names. Each group of processes is attached to a specific namespace instance, which references its own set of resources.

Motivation for a CPU Namespace

Container workloads typically rely on cgroups to enforce CPU and memory limits, but they still obtain system topology information from sysfs or /proc. Applications use that information to decide thread counts, memory allocation, or scheduling policies. Inconsistent or unrestricted visibility of CPU topology can cause:

Unexpected performance variations when the observed physical layout differs from the limits imposed by cgroups.

Security and fairness issues in multi‑tenant environments, e.g., an attacker selecting CPUs that share a bus to launch denial‑of‑service attacks or choosing CPUs close to peripherals (GPUs) to gain latency advantages.

CPU Namespace Design (IBM Prototype)

New namespace type : Introduces a dedicated CPU namespace that is linked to each task_struct. When a process creates a CPU namespace, the kernel allocates a flat virtual‑to‑physical CPU mapping.

Flat virtual CPU mapping : Each virtual CPU identifier inside the namespace is bound one‑to‑one to a physical CPU at namespace creation time. The mapping is stored directly in the task’s data structures, eliminating hierarchical look‑ups and allowing O(1) translation for operations such as sched_setaffinity or cpuset queries.

Namespace‑aware interfaces : Existing control and visibility interfaces (e.g., sched_getaffinity, cpuset files in /proc, and sysfs attributes) are extended to check the calling task’s CPU namespace. Tasks can only see and manipulate the virtual CPU IDs defined by their namespace, preventing leakage of the host’s topology.

Isolation semantics : Child processes inherit the parent’s CPU namespace, preserving the same virtual‑to‑physical mapping unless a new namespace is explicitly created. This ensures consistent views across the entire process tree.

Implementation Highlights

The prototype patches add the following kernel structures and hooks:

struct cpu_namespace {
    unsigned int nr_cpus;          // number of virtual CPUs
    int *virt_to_phys;             // array: virtual ID -> physical CPU ID
    struct list_head list;        // linked list of namespaces
};

/* Hook into task creation */
static int cpu_ns_task_init(struct task_struct *task, struct cpu_namespace *ns) {
    task->cpu_ns = ns;
    return 0;
}

/* Translate virtual to physical ID */
static inline int cpu_ns_virt_to_phys(struct cpu_namespace *ns, int vcpu)
{
    return ns->virt_to_phys[vcpu];
}

These helpers replace the traditional cpu_present_mask look‑ups when a task queries its allowed CPUs.

Performance Evaluation

A set of benchmarks using the Nginx web server was executed inside a container that employed the CPU namespace. Compared with a baseline container that relied on the default sysfs view, the results were:

Memory usage reduced by 92 %–95 % (due to smaller topology data structures).

Request latency decreased by roughly 64 %.

Throughput (requests per second) and total data transfer remained statistically unchanged.

The prototype still has open issues, such as handling hot‑plug CPU events and integrating with existing cpuset controllers, but the initial data suggests that a CPU namespace can improve isolation, security, and performance for containerized workloads.