Ressources d'unité centrale non contrôlées par Solaris Resource Manager

Solaris Resource Manager contrôle uniquement l'utilisation d'UC par les processus de la classe d'ordonnancement SHR. Si des demandes excessives d'une priorité supérieure sont faites par d'autres classes d'ordonnancement, spécialement les classes temps réel (RT) et système (SYS), SHR peut ordonnancer seulement avec les ressources restantes de l'UC.

L'utilisation de la classe RT génère un conflit avec les fonctions de gestion de système de Solaris Resource Manager. Les processus en temps réel obtiennent un accès complet au système afin qu'ils puissent transmettre des réponses en temps réel (habituellement de l'ordre de quelques centaines de microsecondes). Les processus exécutés dans la classe SHR ont par définition une priorité inférieure à celle de tout processus en temps réel, sur lesquels Solaris Resource Manager n'a aucun contrôle. Les processus en temps réel peuvent facilement consommer toutes les ressources disponibles, privant Solaris Resource Manager de ressources à attribuer aux autres processus.

Le serveur NFS est l'un des services exécuté exclusivement dans la classe SYS. Solaris Resource Manager ne peut pas contrôler les démons NFS, car ils sont exécutés dans SYS. La capacité de Solaris Resource Manager à attribuer des ressources de processeur peut être réduite sur les systèmes offrant un service NFS étendu.

Même si des processus exécutent du code de noyau (à l'intérieur d'un appel système), les règles de priorité de tranche de temps habituelles ne s'appliquent pas. La plupart des appels système exécuteront seulement une certaine partie de leurs tâches avant d'atteindre un point de préemption. Cependant, si le système subit une charge élevée d'appels système plus intensifs, cela peut causer une diminution de la réactivité globale, ce qui est hors de la portée de contrôle d'une classe d'ordonnancement.

Si le système manque de mémoire réelle, le goulot d'étranglement d'E/S résultant de l'accroissement du taux d'erreurs de page et des échanges de processus augmente la consommation des ressources de l'UC par le noyau. Des temps d'attente d'E/S importants peuvent indiquer des pertes de capacité d'UC. Encore une fois, cela est hors de la portée d'une classe d'ordonnancement.

La classe d'ordonnancement SHR est un ordonnanceur à temps partagé (TS) qui utilise la même gamme de priorité globale que les ordonnanceurs TS et interactif (IA). Il n'est pas recommandé de combiner l'utilisation de SHR avec TS et IA, sauf pour transférer tous les processus dans ou depuis la classe SHR. L'utilisation du système avec une combinaison de processus des classes SHR et TS diminuera la qualité de l'ordonnancement dans les deux classes. Pour cette raison, Solaris Resource Manager empêche les processus non root de se déplacer ou de déplacer d'autres processus vers les classes TS ou IA. La classe RT fait appel à une autre gamme de priorité et peut être utilisée avec la classe SHR de la même façon que les classes TS et IA.

Si des processus exécutés par le superutilisateur contiennent du code utilisant l'appel système priocntl(2) directement au lieu de la routine de bibliothèque setpriority (3C) pour ajuster les priorités des processus, ils peuvent transférer les processus cibles dans une autre classe d'ordonnancement (habituellement TS). Le code de la routine de bibliothèque setpriority tient compte du fait que l'interface priocntl avec SHR est binairement compatible avec celle de TS, et contourne ainsi le problème. L'option - c de ps( 1) ou l'option -d de priocntl(1) peut être utilisée pour afficher la classe d'ordonnancement des processus.

Le même problème se manifeste avec les processus de privilège de superutilisateur qui utilisent explicitement priocntl(2) pour gérer l'appartenance de classe d'ordonnancement des processus.