Debian configure son noyau pour un serveur, c'est à dire en retirant la préemptabilité (donc les applications ne passent la main que quand elles le veulent, ou si vraiment trop de temps passe). Ça permet d'avoir des performances magnifiques sur un serveur, mais sur un desktop, dès qu'une appli utilise un peu de processeur (au démarrage par exemple), toutes les autres attendent. Ca produit l'effet du «démarrage en parallèle qui n'est pas parallèle» que je décris, les services s'attendant mutuellement.
Comme souvent, tu dis beaucoup de choses avec des mots compliqués. Le problème c'est généralement très approximatif ou complètement faux... Ici donc les applications ne passent la main que quand elles le veulent, ou si vraiment trop de temps passe en est un bel exemple.
CONFIG_PREEMPT permet d'activer ou de désactiver la préemption en mode noyau. Quand elle est désactivé, un thread ne peut pas être interrompu lorsqu'il se trouve en espace noyau. La main est passée à un autre processus (si besoin) au moment ou le thread repasse en espace utilisateur. Si tu as de long chemin d'exécution dans le noyau, alors tu peux avoir un petit manque de réactivité. Avec le CONFIG_PREEMPT, un changement peut s'exécuter alors que le thread est en espace noyau (sous certaines conditions). Par exemple tu peux réagir à une interruption. Quand un thread est en espace utilisateur ça ne change absolument rien.
Je serais bien étonné que CONFIG_PREEMPT change quoi que ce soit à la vitesse de la phase d'init. Cela dit je ne demande qu'à être convaincu...
Après un noyau, environnent de bureau, une distribution, une système de paquet en 6 mois tu passes maintenant à une GUI pour la compile noyau. Tu penses pas que tu devrais plutôt faire une chose correctement plutôt que tout et n'importe comment ?
[^] # Re: séparation
Posté par ckyl . En réponse au journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2. Évalué à 10.
Comme souvent, tu dis beaucoup de choses avec des mots compliqués. Le problème c'est généralement très approximatif ou complètement faux... Ici donc les applications ne passent la main que quand elles le veulent, ou si vraiment trop de temps passe en est un bel exemple.
CONFIG_PREEMPT permet d'activer ou de désactiver la préemption en mode noyau. Quand elle est désactivé, un thread ne peut pas être interrompu lorsqu'il se trouve en espace noyau. La main est passée à un autre processus (si besoin) au moment ou le thread repasse en espace utilisateur. Si tu as de long chemin d'exécution dans le noyau, alors tu peux avoir un petit manque de réactivité. Avec le CONFIG_PREEMPT, un changement peut s'exécuter alors que le thread est en espace noyau (sous certaines conditions). Par exemple tu peux réagir à une interruption. Quand un thread est en espace utilisateur ça ne change absolument rien.
Je serais bien étonné que CONFIG_PREEMPT change quoi que ce soit à la vitesse de la phase d'init. Cela dit je ne demande qu'à être convaincu...
Après un noyau, environnent de bureau, une distribution, une système de paquet en 6 mois tu passes maintenant à une GUI pour la compile noyau. Tu penses pas que tu devrais plutôt faire une chose correctement plutôt que tout et n'importe comment ?