份额

用户的 cpu.shares 属性可用于根据用户的 parent 活动的同级分配 CPU 权利。只有当一个用户具有活动的 child 用户时，该用户的 cpu.myshares 属性才有意义；该属性用于确定针对用户的 CPU 权利的分配。

例如，如果用户 A 和 B 是父节点 P 的唯一的两个子用户，则 A、B 和 P 每个均拥有组 P 内的一个份额（即，A 和 B 的 cpu.shares 设置为 1，而 P 的 cpu.myshares 设置为 1），因而三方各自均拥有合组的权利合计之三分之一的 CPU 权利。

所以，某个用户的实际 CPU 权利取决于父节点的相对权利。这反过来又取决于该父节点的 cpu.shares 相对于该父节点的 peers 及祖父节点的 cpu.myshares 的相对数值，并依此类推沿调度树向上进行比较。

鉴于系统管理的原因，附加到 root lnode 上的进程不受份额属性的影响。附加到 root lnode 上的任何进程均被给予它请求的几乎所有 CPU 资源。

任何大量耗用 CPU 的进程均不得附加到 root lnode 上，这一点非常重要，因为这会严重影响其它进程的执行。为避免这种情况，应该采取以下预防措施：

• 中央管理员帐户应该有自己的 UID，并与超级用户帐户不同。在登录并进行非管理任务时，应使用这个帐户。如果进行管理功能需要超级用户的 UID，则中央管理员应该使用 su(1) 命令更改 UID，同时仍使该帐户附加在自己的 lnode 上。

• srmuser(1SRM) 命令可被用于 init.d(4) 脚本中，并将任何守护程序附加到一个非 root lnode 上。在缺省状态下，在启动脚本中启动的任何进程均具有一个有效的 UID root，这些进程均被附加到该 root lnode 上。用户命令可使守护程序保持 root 的一个有效 UID，并附加到它们自己的 lnode 上。这样就能在任何守护程序大量耗用 CPU 时避免这些问题。

并非调度树中的所有组长都需要代表运行进程的实际用户，在这些情况下，不必把 CPU 的一个份额分配给它们。这样的 lnode 可通过将其 cpu.myshares 属性设置为零而表示。在这样的一个组长中的 cpu.accrue 属性仍包括对其组的所有成员进行的更改。