URL: https://linuxfr.org/users/gouttegd/journaux/des-control-groups-par-defaut-sur-un-systeme-desktop Title: Des control groups par défaut sur un système desktop ? Authors: gouttegd Date: 2012年08月05日T21:29:30+02:00 License: CC By-SA Tags: cgroup, desktop, franglais, firefox et postgresql Score: 20 Dans une [récente discussion](https://linuxfr.org/news/klang-kernel-level-audio-next-generation#comment-1374345) autour du projet KLANG, Riendf me faisait part du problème suivant :> Pour un desktop il faut que ce soit simple de dire:"je suis en train de mater un film/ecouter de la musique, je ne veux pas que ces process ait la moindre latence a cause d'autre chose."> [...]> Et bien je peux te donner les besoins de la majorite des utilisateurs desktop: pouvoir lire du son et de la video de maniere fluide et sans saccades, quoi que ce soit qui tourne a cote et dont ils sont meme pas au courant que ca tourne.> [...]> quand tu lis une video ou du son, c'est pas pour avoir du son hache ou de la video qui saccade parceque windows update ou pre-link a decide que c'etait le moment, a moins d'etre masochiste. Je n’ai personnellement jamais été confronté à une telle situation, mais pour ceux à qui ça arrive, je conçois que ne pas pouvoir lire une vidéo de façon fluide en 2012 doit être passablement frustrant. Et ce n’est probablement pas un problème isolé, puisqu’on se souviendra que c’est le même constat qui avait poussé un certain Con Kolivas à se plonger dans les entrailles de l’ordonnanceur de tâches :> WTF? Jigabazillion bagigamaherz of CPU and we couldn't play audio? Je pense qu’une utilisation somme toute assez basique des [control groups](http://www.kernel.org/doc/Documentation/cgroups/), que les distributions orientées « desktop » pourraient mettre en place par défaut, devrait suffire à éviter ce problème. Il suffirait en effet de deux groupes : * un groupe « system », accueillant tous les processus non-lancés directement par l’utilisateur (notamment, tous les services), auquel on attribuerait 1024 « parts de CPU » (paramètre _cpu.shares = 1024_) ; * un groupe « users », accueillant, à l’opposé, les processus des utilisateurs et auquel on attribuerait, disons, 4096 parts. Ça ne résoudrait pas forcément tous les problèmes, mais ça permettrait déjà de garantir que, lorsque l’utilisateur lit une vidéo ou écroute de la musique, les processus « systèmes » tournant en arrière-plan (rotation des logs, indexation de fichiers, etc.) ne peuvent pas monopoliser plus de 20 % du CPU, ce qui devrait _a priori_ empêcher de pertuber la lecture. Malheureusement, je ne peux pas vérifier chez moi que cette configuration est efficace, puisque je n’ai, de base, _aucun_ problème pour lire une vidéo quoique je fasse à côté. Même quand je mets le paquet, genre en compilant simultanément un noyau, Firefox et PostgreSQL, tout en lisant la vidéo la plus Super Extra Full HD dont je dispose sur mon disque dur, il n’y a rien à faire, la lecture reste désespérement fluide (seul le ventilateur du processeur est là pour me rappeler que j’en demande peut-être un peu trop). Du coup, j’ai beau essayer toutes les configurations de cgroups que je peux imaginer, je ne vois jamais aucune différence, de sorte que je ne sais pas si mon idée est géniale ou bonne pour la poubelle. J’aimerais savoir ce que vous pensez de cette idée. Les distributions orientées « desktop » devraient-elles mettre en place une configuration de ce genre par défaut ? En connaissez-vous qui le font déjà ?