命名空间（Namespace）是 Linux 内核的一个特性，它对内核资源进行分区，使得一组进程看到一组资源，而另一组进程看到一组不同的资源。该功能的工作原理是为一组资源和进程使用相同的命名空间，但这些命名空间引用不同的资源。资源可能存在于多个空间中。此类资源的示例包括进程 ID、主机名、用户 ID、文件名以及一些与网络访问和进程间通信相关的名称。
IBM 工程师 Pratik Sampat 近日发表了 Linux 内核的 CPU Namespace 接口的早期原型。设计这个命名空间是为了解决当前查看可用 CPU 资源的方法的一致性问题，以及解决因了解系统上的资源访问/位置而可能产生的安全问题。
如今，在容器上运行的应用程序在 cgroups 的帮助下执行它们的 CPU、内存限制与要求。然而，许多应用程序通过 sysfs/procfs 继承或以其他方式获得系统的视图，并根据这些信息分配资源，如线程/进程的数量，内存分配。这可能会导致意外的运行行为，并对性能产生很大影响。
除了一致性问题，目前的处理方式也给多租户系统带来了安全和公平使用的影响，例如：
攻击者可以在知道 CPU 节点拓扑的情况下调度工作负载并选择 CPU，从而使总线被淹没而造成拒绝服务攻击；以及识别 CPU 系统拓扑结构可以帮助识别靠近总线和外围设备（如 GPU）的内核，以便从其他工作负载中获得不适当的延迟优势。
因此，由 IBM 领导的 CPU Namespace 提案追求以下设计：
- 这个原型补丁集引入了一个新的内核命名空间机制 —— CPU Namespace。
- CPU Namespace 通过虚拟化逻辑 CPU ID 和创建相同的虚拟 CPU 映射来隔离 CPU 信息。它锁定在 task_struct 上，并且 CPU 转化被设计成扁平的层次结构，这意味着每个虚拟命名空间 CPU 在创建命名空间时都映射到一个物理 CPU，转化速度更快；并且子代不需要向上遍历树来检索转化。
- 该命名空间允许控制和显示接口都能够感知 CPU 命名空间上下文，这样命名空间内的任务只能通过虚拟 CPU 映射获取视图并因此控制它，以及查看可用的 CPU 资源。
在用 Nginx Web 服务器进行的测试中，内存占用率下降了 92-95%，延迟减少了 64%，每秒的请求和传输等吞吐量没有显著变化。虽然目前的设计仍有存在一些缺陷，但随着 IBM 的持续改进，Linux 的性能有望大幅提升。
我的理解是这样，不保证正确。
Thank your for providing a new approach to this problem and thanks for
summarizing some of the painpoints and current solutions. I do agree
that this is a problem we should tackle in some form.
I have one design comment and one process related comments.
Fundamentally I think making this a new namespace is not the correct
approach. One core feature of a namespace it that it is an opt-in
isolation mechanism: if I do CLONE_NEW* that is when the new isolation
mechanism kicks. The correct reporting through procfs and sysfs is
built into that and we do bugfixes whenever reported information is
wrong.
The cpu namespace would be different; a point I think you're making as
well further above:
> The control and the display interface is fairly disjoint with each
> other. Restrictions can be set through control interfaces like cgroups,
A task wouldn't really opt-in to cpu isolation with CLONE_NEWCPU it
would only affect resource reporting. So it would be one half o
上面是链接，搜reporting