L'aimable auteur de l'article cité par
bompi -
Topher Kessler :
en porteur de barbe (voire seulement de barbichette) devant, quotidiennement, arranger cette pilosité selon de complexes critères d'équité, était on ne peut mieux habilité à traiter des procédés du
kernel pour démêler prioritairement les fils à passer au
CPU. Car c'est bien de justice distributive qu'il est question, et de la limite des passe-droits dans cette population stratifiée (ou comment la politique est au cœur d'un Système Logique)...
En résumé : les processus ou fils relèvent de 4 strates de priorité descendante : 01 =
niveau_kernel ; 02 =
niveau_horloge ; 03 =
niveau_Système ; 04 =
niveau_standard. En supposant le processus d'une application comme «
TextEdit» (
) relevant de la strate 04, une commande
renice visant à augmenter le degré prioritaire de ce processus n'impactera - si elle le peut - que la file d'attente des processus ressortissant de la strate 04, en promouvant éventuellement le processus «
TextEdit» en tête de file des processus standards. Le processus «
TextEdit» restera donc devancé par les fils relevant des strates davantage prioritaires 01 à 03.
La strate - pour ne pas dire "caste" - d'appartenance d'un processus fixe donc des limites en priorité "absolue" qui ne peuvent pas être transgressées --> un processus bénéficiaire de la commande
renice ne peut donc que grimper dans la file d'attente spécifique des processus dont le "censeur" du
kernel (le gestionnaire d'emploi du temps processeur :
kernel_scheduler) traite les vœux. Mais ce passe-droit accordé par la commande
renice dans les limites d'une strate de processus, peut très bien rester sans effets notables relativement à d'autres de la même strate, si ces derniers ont d'autres arguments à faire valoir auprès du "censeur" (
kernel_scheduler), comme l'emploi de ressources
hardware (carte graphique et pourquoi pas Wi-Fi ?).
Se pourrait-il que «
Safari» (ou un autre navigateur) s'arrange pour faire valoir un tel argument neutralisant le passe-droit que la commande
renice accorde à l'application lancée par
Alex - concurrence gérée dans le cadre de la strate 04 des processus standard ? En contre-exemple : dès qu'on lance un processus d'encodage de «
HandBrake», une consommation phénoménale de
CPU intervient qui prend la main hégémoniquement sur les autres processus utilisateur : faudrait-il en déduire que «
HandBrake» est une application qui relève du
niveau_horloge ("temps réel") = strate 02 et qui, par là-même, se trouve privilégiée juste en-dessous des processus directs du noyau (et, de fait, «
HandBrake» recourt à un décompte d'horloge pendant tout son processus - comme «
Carbon Copy Cloner» par exemple aussi) ?
Étant donné ces supputations, je propose un test à
Alex. Il existe 2 commandes d'édition des priorités :
nice et
renice (je profite de mon élan
rhétorique pour revenir sur l'emploi de ce mot anglais : "nice", qui veut dire "gentil" - pris ici dans une acception de "courtoisie civile" --> la "courtoisie" d'un processus l'est donc à l'égard des autres : plus un processus est "courtois", plus il s'efface civilement pour laisser à d'autres la place dans la file d'attente, moins par conséquent il se rend prioritaire : il se laisse "passer devant" ; au contraire, moins un processus est "courtois", plus il se montre vachard en remontant incivilement la file d'attente pour "passer devant" les autres : il grimpe donc en position de priorité).
- renice est une commande qui prend un processus en chemin pour affecter sa priorité relative dans la file d'attente constituée d'une strate. Pour l'application d'Alex, le processus ayant été lancé par lui qui en est l'exécutant et semble-t-il relevant de la strate 04, se fait bousculer par les arguments que fait valoir un navigateur internet, également lancé par lui et relevant de la même strate des priorités.
- nice, par contre, est une commande qui lance un processus en lui affectant une priorité et qui, pour ce faire, doit opérer en mode root --> le processus ne va donc plus relever de la strate 04 (processus ordinaires d'utilisateur), mais de la strate 03 (processus-Système dont l'opérateur est root). La commande nice est donc susceptible de faire sauter une strate à un processus utilisateur via le lancement de l'application en mode root. La commande ne se réfère évidemment pas à un PID, puisque le processus de l'application n'est pas déjà lancé, mais à l'exécutable (le fichier exec) recelé dans l'arborescence de l'application at: /Applications/Machin.app/Contents/MacOS/Machin (pour accéder graphiquement à cet exécutable de l'application : sélectionner l'icône de l'app avec un clic secondaire (aka ctrl_clic) --> afficher le contenu du paquet > dossier Contents > dossier MacOS > exécutable --> faire un glisser-déposer dans la fenêtre du «Terminal» au bon emplacement.
Syntaxe de la commande :
Bloc de code:
sudo nice -n -20 /Applications/Machin.app/Contents/MacOS/Machin
--> l'application se lance en droit
root (donc présumablement dans la strate 03 des priorités-Système) avec le passe-droit
-20 qui lui affecte le maximum d'incivilité vacharde à l'endroit des autres et donc le maximum de priorité relative dans sa strate) --> il suffit de lui assigner la tâche voulue --> est-ce que la concurrence d'un navigateur se trouve par là limitée ?
[NB. L'utilisateur de l'application étant root, il y a des risques que l'application se réfère au dossier de compte de root comme logement d'utilisateur pour proposer un point de chute par défaut du produit d'un encodage. Si le "Bureau" est proposé par défaut, il y a des chances que cela corresponde à l'adresse : /private/root/Desktop et pas au Bureau de session de l'utilisateur à l'adresse : /Users/user/Desktop. Vérifier le point de chute renseigné par défaut pour l'éditer s'il y a lieu...]
.
