(Dans la gestion des Pools de traitement partagé)
Cette valeur indique le nombre d'unités de traitement réservées à une utilisation temporaire par les partitions logiques non bridées dans le pool de traitement partagé. Une partition logique peut uniquement utiliser des unités de traitement réservées lorsque la partition logique n'est pas bridée et requiert un nombre de ressources processeur supérieur à celui qui lui est affecté. Les unités de traitement réservées ne peuvent pas être utilisées par des partitions logiques dans d'autres pools de traitement partagé. De plus, les unités de traitement réservées ne peuvent pas être affectées à une partition logique spécifique.
Le pool de traitement partagé par défaut ne dispose pas d'un nombre réservé d'unités de traitement, car le pool de traitement partagé par défaut utilise automatiquement les unités de traitement qui ne sont pas utilisées par les autres pools de traitement partagé.
Par défaut, tous les processeurs qui ne sont pas dédiés à des partitions logiques spécifiques sont groupés dans des 'SharedPorocessor Pool'.
Il est possible alors de définir dans chaque profil de LPAR (en mode débridé/uncapped)une quantité d'unités de traitements disponibles dans ce Shared Pool, sans dépasser le maximum de ce dernier.
Suivant les modèles de serveurs, il est possible de définir plusieurs Shared Processor Pool.
Sur ces systèmes gérés, un Pool nommé 'Default Processor Pool' contient toutes les unités de traitement non utilisées (Processeurs dédiés ou unités réservées aux LPAR ou à d'autres SharedPools. Ce Pool n'a pas de valeurs limites ou réservées.
Un SharedProcessor Pool est défini avec 2 valeurs : Le nombre d'unités de traitement réservées, c'est à celles qui seront toujours affectées à ce Pool, et le nombre maximum d'unités de traitement que le Pool(Les LPARs) peut consommer sur le système entier.
Les unités de traitement sont une mesure de quantité de puissance physique répartie sur les processeurs virtuels.
1 unité de traitement sur 1 processeur physique représente approximativement la puissance d'un processeur dédié.
L'affection des LPARs à des Pool de Processeur Partagés se fait au travers des profils de LPAR.
Une LPAR peut donc être définie avec un mode bridé/capped ou débridé/uncapped.
La quantité d'unités de traitement qu'une partition débridée peut utilisée est limité par le nombre PROCESSEUR VIRTUEL affecté ou par la valeur maximum allouée au SharedProcessorPool.
Au contraire, une partition en mode bridée ne pourra pas utiliser plus que le nombre d'unités de traitements affectés.
Par exemple, deux partitions #2 et #3 sont en mode débridée et une partition #4 est en mode bridée.
Les LPARs 2 et 3 sont définies avec 3 UT et 4 VP.
La partiton 2 utilise actuellement 1 des 3 UT actuellement affectés, mais la LPAR 3 requiert 4 UT.
Comme la LPAR 3 est débridée avec 4 Virtual processors, the firmware autorise l'utilisation d'une UT affectée à la LPAR 2.
Cela permet donc à la partition 3 d'arriver à 4 unités de traitement consommés.
Après la fin de surcharge, le système réaffecte automatiquement l'unité de traitement à la LPAR 2 afin qu'elle puisse l'uiliser selon ses besoins.
La partition #4 est définie avec 2 unités de traitement et 3 processeurs virtuels, mais possède une charge qui nécessite 3 unités de traitements. Comme la partition est bridée(capped), celle-ci ne pourra pas utiliser les unités inutilisées par les LPARS 2 et 3.
Par contre, si la charge de la LPAR 4 descend sous les 2 unités de traitement, les partitions 2 et 3 pourront bénéficier de la puissance ainsi disponible.
Par défaut, les LPAR sont définiess en mode bridé(Capped).
Si une LPAR est définie en mode débridée sans Share Processor POol, elle pourra utilise autant d'unités de traitement que la valeur du nombre de processeurs virtuel définie.
Si la LPAR est dans un Pool partagé, elle ne pourra pas utilser plus que le maximum défini dans le Pool lui-même.
Si plusieurs LPARs nécessite plus de puissance, le système peut distribuer celle-ci en suivant les règles de poids.
Uncapped weight is a number in the range of 0 through 255 that you set for each uncapped logical partition in the shared processor pool. On the HMC, you can choose from any of the 256 possible uncapped weight values. By setting the uncapped weight (255 being the highest weight), any available unused capacity is distributed to contending logical partitions in proportion to the established value of the uncapped weight. The default uncapped weight value is 128. When you set the uncapped weight to 0, no unused capacity is distributed to the logical partition.
Uncapped weight is only used where there are more virtual processors ready to consume unused resources than there are physical processors in the shared processor pool. If no contention exists for processor resources, the virtual processors are immediately distributed across the logical partitions independent of their uncapped weights. This can result in situations where the uncapped weights of the logical partitions do not exactly reflect the amount of unused capacity.
For example, logical partition 2 has one virtual processor and an uncapped weight of 100. Logical partition 3 also has one virtual processor, but an uncapped weight of 200. If logical partitions 2 and 3 both require additional processing capacity, and there is not enough physical processor capacity to run both logical partitions, logical partition 3 receives two additional processing units for every additional processing unit that logical partition 2 receives. If logical partitions 2 and 3 both require additional processing capacity, and there is enough physical processor capacity to run both logical partitions, logical partition 2 and 3 receive an equal amount of unused capacity. In this situation, their uncapped weights are ignored.
The server distributes unused capacity among all of the uncapped shared processor partitions that are configured on the server, regardless of the shared processor pools to which they are assigned. For example, you configure logical partition 1 to the default shared processor pool. You configure logical partition 2 and logical partition 3 to a different shared processor pool. All three logical partitions compete for the same unused physical processor capacity in the server, even though they belong to different shared processor pools.
