La discussion concernant ce correctif spécifique a eu lieu sur la liste de diffusion Ubuntu kernel-team:
https://lists.ubuntu.com/archives/kernel-team/2010-novembre/013498.html
Mais permettez-moi d’essayer d’élaborer de manière encore plus générique la meilleure façon pour un correctif de s’intégrer dans le noyau Ubuntu ...
Tout d’abord, c’est la politique préférée de l’équipe du noyau Ubuntu que les correctifs soient soumis et acceptés en amont avant d’être extraits dans le noyau Ubuntu. L’équipe du noyau Ubuntu a un lourd fardeau de maintenance à devoir maintenir des correctifs en dehors de l’arbre. De plus, si le correctif bénéficie à l'ensemble de la communauté du noyau, il doit d'abord être mis en amont.
Une fois que le correctif a été accepté en amont, il finira par se retrouver automatiquement dans le noyau Ubuntu. Une demande de sélection ou d'extraction peut également être effectuée si vous le souhaitez. Reportez-vous à la page KernelPatches pour plus d'informations.
Si le correctif doit être appliqué en tant que SRU ( mise à jour de version stable ) à une version antérieure d'Ubuntu, il est préférable de l'accepter dans l'application arborescente 2.6.xy stable en amont correspondante. Dans le cadre de notre processus SRU de noyau normal, nous nous basons continuellement sur le dernier noyau stable en amont. Ainsi, nous aurions à nouveau éventuellement le correctif automatiquement.
Leann Ogasawara
la source
Je viens de lire le fil de discussion Lkml et j'espère pouvoir vous donner quelques informations - bien que ce ne soit pas sur la manière d'installer le correctif dans Ubuntu. Comme l'indique une publication sur la liste liée Ubuntu, elle sera probablement dans la version 2.6.38 de toute façon.
Le correctif regroupe automatiquement les processus en fonction des TTY. Il y a beaucoup de discussions / arguments sur le lkml qui dit que cela signifie que ce n'est pas pertinent pour une utilisation de bureau typique - cela ne fait aucune différence pour les applications interactives. Les scénarios de test sont tous basés sur "démarrer une tâche gourmande en ressources CPU à partir d'un terminal, puis examiner la réactivité d'une autre tâche". Donc, compiler un noyau et essayer de regarder une vidéo, par exemple.
Cela ne veut pas dire que ce n’est pas bon, mais les gros titres de type «La réactivité des postes de travail améliorée d’un ordre de grandeur» pourraient être trompeurs si vous n’exécutez jamais de tâches gourmandes en ressources processeur connectées à un téléscripteur. Je peux me tromper bien sûr!
Il y avait quelques mentions sur les moyens d'obtenir un résultat très similaire en ajoutant à vos scripts bash et en permettant à tous les utilisateurs de créer des groupes de contrôle. Cela ne fonctionnera que si les noyaux Ubuntu actuels ont des groupes de contrôle activés. Les postes pertinents sont:
Évidemment, cela ne répond pas à la question, mais cela pourrait être utilisé pour déterminer si le patch est aussi magique que prévu.
la source
L'accent est à moi. La seule façon de l'obtenir de manière prise en charge est d'attendre qu'Ubuntu l'envoie dans le noyau Ubuntu. Comme il s’agit en réalité de figurer sur la liste de diffusion du noyau, les tests sont à ce point anodins et l’analyse est assez anecdotique et j’imagine qu’il faudra un certain temps avant qu’elle soit prête à être déployée en masse.
Quelque part entre la prochaine version et une longue période serait ma conjecture inculte.
Mais si vous êtes un grand garçon (ou une fille) et que vous pouvez faire face à un noyau cassé en cas de problème (vous savez comment utiliser grub), vous pouvez patcher et compiler votre propre noyau.
Téléchargez un patch. Il existe différentes versions mais le meilleur en soi a été publié ci-dessous par un autre utilisateur: http://pavlinux.ru/krnl/sched_autogroup-2.6.36.patch.bz2
Téléchargez le code source de la version de vos correctifs. Dans ce cas, 2.6.36. Vous pouvez obtenir les sources du noyau vanilla (d'origine, non modifié par l'équipe du noyau Ubuntu) à partir de kernel.org et l'extraire.
Enregistrez le correctif quelque part et appliquez-le
cden entrant dans le répertoire source du noyau et en exécutant:patch -p1 < /path/to/patch(vous avez besoin dupatchpaquet pour cela ... ce qui, je pense, fait partie debuild-essentials'il n'est pas installé par défaut)Et ensuite, continuez avec le reste du processus de construction "à l'ancienne" ... Je ne voudrais vraiment pas m'embêter avec les nouvelles méthodes car elles visent les sources de noyau approuvées par Ubuntu / Debian ... De plus, l'ancienne méthode semble plus facile ( tome).
Construire des noyaux n'est pas difficile, mais vous pouvez le gâcher si vous vous écartez trop du chemin accepté. Et vous ne recevrez pas de soutien officiel si les choses tournent mal.
Alternativement, de plus en plus de noyaux émergent avec le correctif intégré (ou au moins dans l’arborescence source, dans l’attente de la prochaine version).
Remarque: ces deux noyaux (et probablement d’autres aussi) s’écartent de la manière de faire les noyaux d’Ubuntu. Vous constaterez peut-être (comme je l’ai fait lors de ma migration vers Liquorix) que la mise à l’échelle de fréquence du processeur cesse de fonctionner ou que la suspension est interrompue. Il y a généralement des correctifs et des solutions de contournement, mais il est probable que vous n'obtiendrez pas de support de la part de AskUbuntu ou du reste de la communauté Ubuntu, car nous ne pouvons pas vérifier tous les noyaux existants.
la source
Vous pouvez utiliser un simple "hack" posté par un développeur RedHat sur une liste de diffusion, qui ne nécessite pas de patch du noyau pour obtenir la même chose. Lisez à ce sujet ici: Alternative au "correctif de noyau 200 lignes qui fait des merveilles" que vous pouvez utiliser tout de suite
la source
Depuis le 2011-01-18, Linux 2.6.38-rc1 inclut ledit correctif.
Voir les actualités sur Phoronix et l'article de Linus .
Depuis le 2011-01-29, la version quotidienne de Natty Narwhal est fournie avec Linux 2.6.38.
Donc, il y a actuellement deux solutions:
la source
Je viens de prendre cette discussion maintenant et c'est très intéressant. J'ai écrit un petit article de blog sur la manière d'activer le correctif cgroup sur Ubuntu 10.10.
Je n'ai pas vraiment testé si cela fonctionnait ou non, les retours seraient donc formidables!
la source