M
Membre supprimé 1060554
Invité
La phase boot.efi n'est donc absolument pas impactée : celle où le boot_loader charge le kernel en RAM > puis lui injecte les extensions en tableau --> que l'extension qui gère le TRIM soit présente ou absente du tableau ne change absolument rien. Ce n'est donc pas un problème à l'injection.
J'avais dû mal à concevoir une explication à ce niveau-là et ma conjecture (spéculative) d'une extension (celle du TRIM) qui serait restée hors-cache et qui aurait dû être injectée isolément > ce afin d'expliquer un délai supplémentaire dans le temps d'opération du boot.efi --> doit être complètement abandonnée.
C'est donc dans la phase opératoire correspondant à l'affichage de la barre horizontale que la différence de délai de 15" intervient. Mais j'ai l'impression de tomber de Charybde en Scylla en ce qui concerne les problèmes à concevoir la « raison des effets ».
Car manifestement la barre horizontale désigne la phase globale de "chargement du Système". Notion confuse s'il en est, puisque 2 séquences sans commune mesure se succèdent pendant ce fameux "chargement du Système" --> la séquence primaire "intra-kernel" et la séquence secondaire "extra-kernel".
Lorsqu'il n'y avait pas à l'écran de boot de barre de chargement qui crée la confusion --> on voyait une roue crantée giratoire pendant toute la séquence primaire "intra-kernel" --> ce qui permettait de s'apercevoir que la prise en charge du Système BSD par le kernel est un opération de grande envergure, vu le temps que ça prenait. À un moment donné --> cette roue crantée disparaissait > il y avait un saut d'écran --> ce qui signifiait clairement que le processus extra-kernel de launchd était en cours. Càd. que les services de l'OS étaient en train d'être démarrés. La distinction des séquences était claire, graphiquement parlant.
Je trouve qu'à présent l'artefact d'une barre de progression continue dissimule la différence fondamentale entre séquence intra-kernel et séquence extra-kernel : prise en charge du Système et initialisation de l'OS.
Malgré tout > quand tu dis -->
- je conjecturerais (spéculativement) que l'arrêt en question consiste dans le passage de la séquence intra-kernel (Système) à la séquence extra-kernel (launchd).
Sans l'extension du TRIM chargée --> "chargement rapide" jusqu'à l'écran de connexion ; avec l'extension du TRIM chargée --> "reprise lente" jusqu'à l'écran de connexion. Il est clair que ce qui est pointé là est l'activité extra-kernel du Serveur launchd : launchd exécute vite son service d'initialisation sans le TRIM > plus lentement avec le TRIM.
Ce constat (empirique) me pose un problème pour en rendre raison théoriquement. Car launchd n'a rien à voir avec le TRIM ! Le TRIM est l'affaire du kernel, une affaire intra-kernel > pas l'affaire de launchd, une affaire extra-kernel. Pourquoi launchd se trouve-t-il ralenti dans son activité de service par un facteur qui n'est absolument pas de son ressort mais de celui du kernel ?
Je vais avancer une conjecture (spéculative) : si on admet que le kernel attende (temporellement) la fin du chargement du Système -BSD pour lancer l'opération du TRIM de l'extension qui a été injectée précédemment --> alors on peut concevoir une stase entre la fin de la séquence intra-kernel et le démarrage de launchd. Ma conjecture me satisfait modérément : elle consiste à dire --> le lancement de launchd serait différé. Après quoi l'exécution du service de launchd serait aussi rapide en soi. Si j'en suis modérément satisfait --> c'est que je ne suis pas sûr que ça "colle" exactement avec l'observation : "reprise lente".
J'avais dû mal à concevoir une explication à ce niveau-là et ma conjecture (spéculative) d'une extension (celle du TRIM) qui serait restée hors-cache et qui aurait dû être injectée isolément > ce afin d'expliquer un délai supplémentaire dans le temps d'opération du boot.efi --> doit être complètement abandonnée.
C'est donc dans la phase opératoire correspondant à l'affichage de la barre horizontale que la différence de délai de 15" intervient. Mais j'ai l'impression de tomber de Charybde en Scylla en ce qui concerne les problèmes à concevoir la « raison des effets ».
Car manifestement la barre horizontale désigne la phase globale de "chargement du Système". Notion confuse s'il en est, puisque 2 séquences sans commune mesure se succèdent pendant ce fameux "chargement du Système" --> la séquence primaire "intra-kernel" et la séquence secondaire "extra-kernel".
- la séquence primaire "intra-kernel" désigne la phase où, le kernel devenu un moteur autonome avec toutes ses extensions, prend en charge les structures additionnelles fondamentales qui constituent le « Système » (BSD). À l'issue de cette phase > le kernel est le noyau opérateur d'un « Système».
- cette opération accomplie > le kernel exécute le programme de launchd > càd. lance le Serveur qui va initialiser les services de l'OS à proprement parler. On est là dans une séquence "extra-kernel". launchd, par exemple, va mettre en route le "service d'annuaire" (Open Directory) - soit toutes les routines logicielles qui font "tourner" l'OS. Toutes ces tâches vont jusqu'au moment d'ouvrir une session graphique d'utilisateur.
Lorsqu'il n'y avait pas à l'écran de boot de barre de chargement qui crée la confusion --> on voyait une roue crantée giratoire pendant toute la séquence primaire "intra-kernel" --> ce qui permettait de s'apercevoir que la prise en charge du Système BSD par le kernel est un opération de grande envergure, vu le temps que ça prenait. À un moment donné --> cette roue crantée disparaissait > il y avait un saut d'écran --> ce qui signifiait clairement que le processus extra-kernel de launchd était en cours. Càd. que les services de l'OS étaient en train d'être démarrés. La distinction des séquences était claire, graphiquement parlant.
Je trouve qu'à présent l'artefact d'une barre de progression continue dissimule la différence fondamentale entre séquence intra-kernel et séquence extra-kernel : prise en charge du Système et initialisation de l'OS.
Malgré tout > quand tu dis -->
Clairement à la fin de la barre de progression. Il y a un petit arrêt et à partir de cet arrêt deux scénarii
- je conjecturerais (spéculativement) que l'arrêt en question consiste dans le passage de la séquence intra-kernel (Système) à la séquence extra-kernel (launchd).
Sans l'extension du TRIM chargée --> "chargement rapide" jusqu'à l'écran de connexion ; avec l'extension du TRIM chargée --> "reprise lente" jusqu'à l'écran de connexion. Il est clair que ce qui est pointé là est l'activité extra-kernel du Serveur launchd : launchd exécute vite son service d'initialisation sans le TRIM > plus lentement avec le TRIM.
Ce constat (empirique) me pose un problème pour en rendre raison théoriquement. Car launchd n'a rien à voir avec le TRIM ! Le TRIM est l'affaire du kernel, une affaire intra-kernel > pas l'affaire de launchd, une affaire extra-kernel. Pourquoi launchd se trouve-t-il ralenti dans son activité de service par un facteur qui n'est absolument pas de son ressort mais de celui du kernel ?
Je vais avancer une conjecture (spéculative) : si on admet que le kernel attende (temporellement) la fin du chargement du Système -BSD pour lancer l'opération du TRIM de l'extension qui a été injectée précédemment --> alors on peut concevoir une stase entre la fin de la séquence intra-kernel et le démarrage de launchd. Ma conjecture me satisfait modérément : elle consiste à dire --> le lancement de launchd serait différé. Après quoi l'exécution du service de launchd serait aussi rapide en soi. Si j'en suis modérément satisfait --> c'est que je ne suis pas sûr que ça "colle" exactement avec l'observation : "reprise lente".