桌面环境的唯一作用是将用户连接到他们的应用程序。这包括从启动应用程序到实际显示应用程序的方方面面，但也包括管理它们并确保它们公平运行。每个人都熟悉任务管理器(如ksysGuard)的概念，但随着时间的推移，他们跟不上应用程序开发的方式或Linux的最新发展。
曾经有一段时间，一个PID==一个应用程序。kwrite进程代表Kwrite，Firefox进程代表Firefox，很简单。但这种情况已经改变了。举个极端的例子：平房里的不和谐是13个过程！
它基本上使我们的任务管理器的进程视图不可用。所有的名字都是随机的胡言乱语，试图杀死应用程序或设置好的级别变成了一场猜谜游戏。父母树可以提供帮助，但它们只能带给你这么多。
它对我来说是不可用的，它可能对任何用户都是不可用的，而且会妨碍你感觉自己在控制你的电脑。
因为它是一个执行高度复杂的图形操作的高度复杂的应用程序，所以CPU会很吃力。
对于内核调度器，它只能看到14个不透明的进程。它不知道它们被归为两个不同的东西。它不可能拿出公平的东西。
(警告：显然大多数进程都处于空闲状态，我忽略了线程以表明观点，请不要写下这一点)。
目前，应用程序的唯一元数据显示在窗口上。要在ksysGuard(或任何其他系统监视器)中显示用户友好的名称和图标，我们必须获取所有进程的列表、获取所有窗口的列表并执行mashup。提出任意启发式算法来处理不稳定和混乱的父PID。
在等离子体的任务管理器中，我们在相关窗口旁边显示音频指示器，我们通过将正在播放的音频的PID与窗口的PID进行匹配来实现这一点。对于这个简单的案例来说很容易。然而，一旦我们进入多进程，我们就必须跟踪父PID，并且每个修复都只是在一个bug和另一个bug之间交替。
我们会丢失有关我们催生的应用程序的信息。我们有错误报告，人们有两个不同的任务管理器条目，分别对应于"；Firefox&34；和"；Firefox(Nighly)&34；然而，一旦该进程产生，信息就会丢失-应用程序会将其自身报告为一个一致的名称，并且我们的任务栏会被混淆。
现代的sysadmin处理的不是进程，而是cgroup。cgroup管理器(通常是systemd)将每个服务派生为一个cgroup。它使用cgroup来知道什么在运行，内核可以看到什么东西属于一起。
在桌面上，扁平包将在cgroup中生成自身，以便它们可以使用相关的名称空间功能。
您可能已经在使用Cgroup了。作为跨桌面努力的一部分，我们希望将cgroup带到整个桌面。
cgroup使用的另一个关键部分是切片的概念。Cgroup基于层次化结构，将片作为划分资源使用的逻辑位置。我们不全局调整资源，我们调整片内的资源，然后它向调度器提供信息。
从概念上讲，您可以想象我们只是在树的级别内调整资源。然后内核神奇地处理剩下的部分。
更多信息可以在这个优秀的系列“用cgroup统治世界”中找到。
这意味着我们可以设置一些预定义的切片。在相关的用户切片中，这将由共享的。
这些切片中的每一个都可以获得一些开箱即用的默认优先顺序和OOM设置。
现在我们正在使用切片，并且只调整切片内的相对权重，我们可以将资源优先级转移到拥有聚焦窗口的应用程序。
只有当您的系统同时从多个来源满负荷运行时，这才会有任何效果，但它可以提供更圆滑的响应，而不会有任何缺点。
NICE是一个单一的值，在整个系统中是全局的。正因为如此，用户进程只能降低，但决不能提高，以避免扰乱系统。对于切片，我们只调整与我们切片内的服务相比的相对权重。因此，让用户完全控制他们的切片是安全的。对应用程序的任何调整都不会影响系统服务或其他用户。
它也不会与应用程序显式设置的NICE值冲突。如果我们将kDevelopment设置为具有更大的CPU重量，那么clang不会在编译时突然接管整个计算机。
Cgroup提供了许多新功能，这些功能在每个进程级别上是不提供的。
我们可以给OOM杀手提供提示，不仅仅是重量，还有应该被认为是正常的预期范围。
所有这些对于用户/系统管理员来说都很容易添加。使用Drop in，您只需将一个.service文件[示例文件链接]添加到~/.config/systemd/user.control/[email protected]并操作其中的任何一个即可。
[警告，其中一些功能适用于作为新的临时服务创建的应用程序，而不是使用当前合并到KDE/Gnome中的作用域的精简版本-也许值得一提的是]。
血浆5.19和最近的Gnome现在将应用程序产卵到各自的cgroup中，但我们还没有从这一点上得到结果。
如果从现有应用程序派生新应用程序，请确保使用ApplicationLauncherJob或CommandLauncherJob并设置各自的服务。然后，所有其他事情都会自动处理。无论如何，您都应该使用这些类来生成新服务。
对发射的改变相对较小，但在等离子体中达到这一点并不容易-有很多边缘情况正确地扰乱了分组。
如果某个应用程序是DBUS激活的(例如我们的屏幕截图工具)，则DBUS激活不知道相关的.ktop文件。
此外，为了充分利用片，我们需要将所有后台进程移到托管服务和片中。这值得再发一篇(同样长的)博客文章。
这是一场寻找这些边缘案例的战斗。在运行您的系统时，请运行systemd-cgls并指出任何不在其相应cgroup中的应用程序(还不是后台服务)。
因为我们只是添加元数据，所以现在使用的所有东西都将继续像现在一样工作。所有现有工具的工作方式完全相同。在我们的任务管理器中，我们仍然会保留一个进程视图(不管怎样，它仍然很有用)，我们不会放入任何依赖于当前cgroup元数据的代码。我们将保留现有的将窗口与外部事件进行匹配的启发式方法，cgrou元数据将是其中的一个重要影响因素。情况不会变得更糟，但我们不会利用这里讨论的新功能，