CPU 資源不受 Solaris Resource Manager 的控制

Solaris Resource Manager 只控制 SHR 排程類別中的處理所使用的 CPU。如果其他排程類別提出優先順序較高的過度要求，特別是即時 (RT) 及系統 (SYS) 兩種類別的話，那麼 SHR 就只能排程剩餘的 CPU 資源。

RT 類別的使用會與 Solaris Resource Manager 軟體控制系統的功能相衝突。即時處理會取得完整的系統存取權，特別是因為這樣它們才能做出即時的回應（速度大約是數百微秒）。SHR 類別中執行的處理優先順序顯然會比即時類別中的任何處理都來得低，而 Solaris Resource Manager 又沒有即時處理的控制權。即時處理會輕易地佔用所有可用的資源，幾乎不留給 Solaris Resource Manager 任何資源好配置給剩餘的處理。

值得一提的是，有一種完全在 SYS 類別中執行的系統服務，稱為 NFS 伺服器。Solaris Resource Manager 無法控制 NFS 常駐程式，因為它們在 SYS 中執行。Solaris Resource Manager 產品配置處理機資源的功能，在提供密集 NFS 服務的系統之上可能效果不彰。

當處理正在執行 kernel 內碼（在一個系統呼叫之內）時，不適用一般性的時間分割強取規則。大多數的系統呼叫只能在到達一個強取點之前完成有限的工作量。不過如果有許多更密集的系統呼叫在影響系統的話，可能會造成整體回應效率的降低，並且超出排程類別的控制範圍之外。

如果系統缺乏可用的真正記憶體，那麼隨著缺頁率的增加及處理交換的增加，會造成 I/O 的瓶頸而導致 CPU 的 kernel 佔用增加。在 I/O 上等待太長的時間可能會喪失 CPU 的執行功率。同樣地，這也在排程類別的控制範圍之外。

SHR 排程類別是一種分時 (TS) 排程器。它和 TS 以及 IA 排程器一樣使用相同的全域優先順序範圍。SHR 不適合用來與 TS 和 IA 混合使用，除非是用於將所有處理移入或移出 SHR 類別時。以 SHR 和 TS 類別的混合處理來進行系統操作，會使這兩種類別排程行為的品質降低。因此 Solaris Resource Manager 不允許非 root 的處理將自己或其他處理移入 TS 或 IA 類別。RT 類別使用一種代用優先順序範圍，而且可以和 SHR 類別一起使用，就好像使用 TS 和 IA 類別一樣。

假如超級使用者所執行的程序包含程式碼，而且這程式碼使用 priocntl(2) 系統呼叫，而不以 setpriority(3C) 程式庫常式來調整處理優先順序的內碼，那麼它們會將目標處理移入另一個排程類別中（通常是 TS）。因為 setpriority 程式庫常式內碼可以使 SHR 的 priocntl 介面與 TS 的介面二進位相容，因此能避免問題發生。指令： -c 可以使用 ps(1)-d 可以使用 priocntl(1) 選項來顯示程序的排程類別。

超級使用者權限處理也會發生同樣的難題，它堅持使用 priocntl(2) 來管理處理的排程類別成員身份。