Pourquoi la version 12.04 supprime-t-elle la saveur du noyau -server?


13

Ubuntu supprime la saveur -server, comme spécifié dans les notes de version du 12.04:

Comme pour la version bêta-1, le noyau bêta-2 ne comporte plus de versions de noyau amd64 -server et -generic distinctes. Ceux-ci ont été fusionnés en une seule saveur de noyau générique pour aider à réduire le fardeau de la maintenance pendant la durée de cette version LTS.

Les différences entre -generic et -server semblent être liées à la préemption, à l'interruption du minuteur et au planificateur d'E / S, comme indiqué sur: https://help.ubuntu.com/10.10/serverguide/C/preparing-to-install .html # intro-kernel-diffs

Je demande des spécifications techniques.

  1. Qu'est-ce-qu'on fait maintenant?
  2. L'édition serveur exécutera-t-elle le noyau du bureau sans perte de performances?
  3. Est-ce justifié d'une manière ou d'une autre?
  4. Que se passe-t-il avec ces différences?
  5. Peuvent-ils être modifiés dans l'espace utilisateur?
  6. Il n'y a pas d'application à partir du 12.04?
  7. Si la réponse est oui, ce changement entraînera une baisse des performances?

Tous sont des questions auxquelles on peut répondre. Je demande un changement spécifique sur un paquet, pas autre chose.

Réponses:


10

Comme vous l'avez remarqué dans les annonces de version, les versions générique et noyau du serveur ont été fusionnées pour la version 12.04 afin de réduire la charge de maintenance pendant la durée de vie du LTS. Les deux versions du noyau ne différaient en fait qu'en ce qui concerne les 2 principales options de configuration du noyau: le planificateur d'E / S par défaut et le modèle de préemption.

Cela a été discuté en détail sur la liste de diffusion de l'équipe du noyau Ubuntu

Comme indiqué dans ce thread, le planificateur d'E / S par défaut est passé de «date limite» à «cfq». Cependant, toute personne souhaitant rester avec le planificateur d'E / S Deadline pourrait le faire au démarrage en définissant elevator=deadline.

Le modèle de préemption est passé de CONFIG_PREEMPT_NONE à CONFIG_PREEMPT_VOLUNTARY. Pour le moment, je n'ai malheureusement pas de référence de performance à vous indiquer. J'espère que cela aide certains. Merci.


7

Vous répondez à votre question «pourquoi» dans le devis que vous fournissez - car il est plus facile de maintenir cette façon. La fonctionnalité du noyau est assez bien paramétrée, vous pouvez changer des choses comme le planificateur au moment de l'exécution, donc il n'y a pas de besoin pressant de différentes valeurs par défaut à compiler.

Pour les raisons exactes et la discussion des détails que vous auriez à demander sur la liste de diffusion Ubuntu KernelTeam - voir la page d'informations du KernelTeam Wiki pour les coordonnées.


2

Ce qui se passe maintenant, c'est qu'il n'y a qu'un seul noyau pour le serveur et le bureau. Le planificateur d'E / S peut être modifié au moment de l'exécution si vous le souhaitez, mais CFQ est le planificateur le plus complet et le plus activement entretenu, c'est donc un bon paramètre par défaut. Celui que vous utilisez ne fait aucune différence dans la plupart des charges de travail. Le noyau du serveur utilisé pour désactiver la préemption du noyau même volontaire parce que théoriquement , il pourrait donner un peuun meilleur débit, mais je ne suis au courant d'aucune mesure de performance qui montre réellement un avantage, donc dans la pratique, les serveurs ne seront pas affectés par le passage au modèle de prémotion de bureau. Le noyau est également sans tick (CONFIG_NO_HZ), ce qui signifie qu'il ne planifie les interruptions du minuteur qu'en cas de besoin en fonction des minuteurs d'application en cours d'exécution plutôt qu'à un intervalle fixe, et je pense que cela a été le cas pour plusieurs versions maintenant, malgré ce que dit le guide du serveur .

TL; DR: Il n'y avait aucun avantage à maintenir un autre noyau pour les serveurs, donc la pratique s'est arrêtée.


Le planificateur d'E / S fait en effet une différence, en particulier pour les charges de travail de virtualisation. Jetez un œil ici: publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaat/… , il conclut "dans l'ensemble, la figure montre que le planificateur d'E / S de date limite surpasse le planificateur d'E / S CFQ, en particulier dans scénarios multithread " .
syneticon-dj
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.