3.11. Optimisations dans l'espace utilisateur

La réduction de la charge de travail effectuée par le matériel d'un système est fondamentale à l'économie d'énergie. Ainsi, même si les changements décrits dans le Chapitre 3, Infrastructure et mécanique principale permettent au système d'opérer dans divers états de consommation d'énergie réduite, les applications dans l'espace utilisateur qui requièrent un travail non-nécessaire de la part du matériel du système empêchent le matériel d'entrer dans ces états. Lors du développement de Red Hat Enterprise Linux 6, des audits ont été entrepris dans les domaines suivants afin de réduire les demandes non-nécessaires sur le matériel :
Réveils réduits

Red Hat Enterprise Linux 6 utilise un noyau tickless (ou sans « tic », reportez-vous à la Section 3.4, « Noyau Tickless »), qui permet aux CPUs de rester plus longtemps dans des états inactifs plus profonds. Cependant, le timer tick (ou compteur de « tics ») n'est pas la seule source de réveils CPU excessifs, et les appels de fonctions des applications peuvent aussi empêcher les CPUs d'entrer ou de rester en état inactif. Les appels de fonctions non-nécessaires ont été réduits dans plus de 50 applications.

Stockage réduit et E/S réseau

Les entrées ou sorties (E/S) de périphériques de stockage et d'interfaces réseau forcent les périphériques à consommer de l'électricité. Pour les périphériques de stockages et réseau qui proposent des états d'alimentation réduits lorsqu'ils sont inactifs (par exemple, ALPM ou ASPM), ce trafic peut empêcher le périphérique d'entrer ou de rester dans un état inactif, et peut ainsi empêcher les disques durs de réduire leur vitesse de rotation lorsqu'ils ne sont pas utilisés. Les demandes excessives et non-nécessaires sur le stockage ont été minimisées dans certaines applications. En particulier, les demandes qui empêchaient les disques durs de réduire leur vitesse de rotation.

Audit initscript

Les services qui démarrent automatiquement qu'ils soient requis de le faire ou non, présentent une perte des ressources du système potentielle. Ces services devraient plutôt être par défaut « off » (éteints) ou « on demand » (à la demande) dans la mesure du possible. Par exemple, le service BlueZ, qui active la prise en charge Bluetooth, se mettait auparavant automatiquement en route, dès lors que le système était allumé ; et ce, que du matériel Bluetooth soit présent ou non. L'initscript BlueZ vérifie maintenant que du matériel Bluetooth est présent sur le système avant de lancer ce service.