CPU Resources 不受 Solaris Resource Manager 控制

Solaris Resource Manager 只对 SHR 调度类中的进程的 CPU 使用加以控制。如果其它调度类，特别是 real-time (RT) 和 system (SYS)，以较高优先权提出过多要求的话，则 SHR 只能对剩余的 CPU 资源进行调度。

RT 类的使用与 Solaris Resource Manager 软件对系统的控制能力相冲突。实时进程获得对系统的完全访问，特别是为了能够提供实时的响应（通常是几万分之一秒）。依照定义，SHR 类中运行的进程所拥有的优先权比任何实时运行的进程都要低，而 Solaris Resource Manager 并不控制 RT 进程。实时进程很容易就用尽全部的可用内存，使得没有为 Solaris Resource Manager 留下任何资源用于分配给其余的进程。

一个值得注意的完全在 SYS 类中运行的系统服务就是 NFS 服务器。Solaris Resource Manager 无法控制 NFS 守护程序，因为它们是在 SYS 中运行的。在提供广泛的 NFS 服务的系统上，Solaris Resource Manager 产品的分配处理器资源的能力可能会被削弱。

在进程（在系统调用内）执行内核代码时，通常的时间片抢先规则并不适用。大多数系统调用只是进行了适中数量的工作就到达了一个抢先点。但是，如果系统承担的是更加剧烈的系统调用的高负载，则有可能导致整体响应下降，并且是在调度类的控制范围之外。

如果系统缺乏可用的物理内存，则随着页面故障率以及进程交换的增加，所导致的 I/O 瓶颈使得内核的 CPU 消耗增加。等候 I/O 时间太长，可能意味着 CPU 负载能力的损失。而这又是在调度类的控制范围之外。

SHR 调度类是一个分时 (TS) 调度程序。其所使用的全局优先权范围与 TS 和交互式的 (IA) 调度程序相同。除在将所有的进程移入或移出 SHR 类的过渡期间之外，把 SHR 与 TS，LIA 混在一起使用是不合适的。SHR 和 TS 类混合进行系统操作，将使两类的调度性能均遭到削弱。出于这个原因，Solaris Resource Manager 防止非 root 进程将其自身或者其它进程移到 TS 或者 IA 类。RT 类使用一个替代性的优先权范围，可以与 SHR 类一同使用，就象与 TS 和 IA 类一同使用那样。

如果超级用户所运行的进程包含直接使用 priocntl(2) 系统调用的代码，而不是使用 setpriority(3C) 库例行程序来调节进程优先权，则目标进程就可能被移动到另一个调度类（一般是TS）之中。 setpriority 库例行程序代码说明一个事实，即至 SHR 的 priocntl 接口是与 TS 二进制兼容的，并因此避免了出现问题。ps1 的 -c 选项或 priocntl(1) 的 -d 选项可用于显示进程的调度类。

显式地使用 priocntl(2) 来管理进程的调度类成员资格的超级用户特权进程也存在同样的难点。