Journal Des control groups par défaut sur un système desktop ?

Posté par (page perso) . Licence CC by-sa
20
5
août
2012

Dans une récente discussion 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, 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à ?

  • # À l'ouest rien de nouveau

    Posté par . Évalué à 10.

    C'est déjà implémenté dans systemd, et le scheduler du noyau a eu un patch qui a fait beaucoup de bruit y'a quelques mois (ou 1 an ou 2, je sais plus) pour ajouter une fonctionnalité similaire : ordonnancement plus équitable en fonction des sessions… C'est ce qui fait qu'un make -j 64 dans un shell va pas faire ramer ta vidéo…

    • [^] # Re: À l'ouest rien de nouveau

      Posté par (page perso) . Évalué à 1.

      J’avais oublié l’existence de ce patch, ça explique peut-être effectivement pourquoi chez moi ça marche tout seul (quoique je n’avais déjà pas de problème avant le noyau 2.6.38). Je trouve néanmoins dommage qu’un tel comportement soit codé « en dur » dans le noyau, alors qu’on peut obtenir la même chose de façon plus paramétrable en jouant avec les cgroups depuis l’espace utilisateur.

      En tout cas, je retiens le coup du make -j 64 pour charger mon processeur, du coup je me rends compte que mon test avec seulement trois compilations en parallèle, ça faisait petit joueur…

  • # Qui a ce problème?

    Posté par (page perso) . Évalué à 4.

    J'ai une configuration assez ancienne (cf playnewton) et même avec mon serveur et mes applis web, Eclipse, Qt Creator, deux navigateurs et quelques autres applications lancés presque en permanence, mes vidéos ne rament pas, même quand c'est du flash qui pue.

    Il doit falloir bien surcharger une config antique pour avoir des problèmes, non?

    http://devnewton.bci.im

    • [^] # Re: Qui a ce problème?

      Posté par (page perso) . Évalué à 4.

      «Il doit falloir bien surcharger une config antique pour avoir des problèmes, non?»

      Mouais,je trouve pas tant que ça. Enfin, ça dépend ce qu'on appelle «antique», mais sur mon vieux laptop qui marche pas trop mal mais a quelques années et était déjà le modèle bon marché de l'époque (en gros, 1GO de ram, un seul proc, un seul coeur, et un disque dur pas très rapide), ça m'arrive assez souvent d'avoir les vidéos qui rament quand y'a d'autres trucs de lancés. Après j'ai plutôt l'impression que ça bloque au niveau des accès disques ou quand il commence à swapper un peu trop que vraiment sur un truc CPU.

      • [^] # Re: Qui a ce problème?

        Posté par (page perso) . Évalué à 2.

        Après j'ai plutôt l'impression que ça bloque au niveau des accès disques ou quand il commence à swapper un peu trop que vraiment sur un truc CPU.

        C’est une possibilité en effet. Si ça vient de là, a priori on peut appliquer la même stratégie que ce que je proposais, mais avec le contrôleur blkio, afin de garantir aux applications de l’utilisateur une certaine proportion de la bande passante disque.

        • [^] # Re: Qui a ce problème?

          Posté par (page perso) . Évalué à 5.

          Le swap respecte-t'il cette politique ou non, si ce n'est pas le cas, ça me semble inutile.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Qui a ce problème?

            Posté par (page perso) . Évalué à 1.

            Je présume que oui. Si j’ai bien compris, c’est un thread noyau dédié, kswapd, qui se charge de swapper les pages. Comme les threads noyaux peuvent être placés dans des cgroups de la même façon que les processus de l’espace utilisateur, il suffit a priori de placer kswapd dans le cgroup « system » pour que les limitations de ce groupe s’appliquent à lui.

    • [^] # Re: Qui a ce problème?

      Posté par (page perso) . Évalué à 2.

      Mon ordinateur principal a ete pendant 1 an un gdium (le disque dur etait une cle usb), puis pendant 2 ans un eeepc (un peu mieux, mais ca restait une faible machine avec 1 go de RAM et des composant globalement faiblard et lent). Je peux te dire que je faisais gaffe a quel film je jouais (je pouvais pas jouer tout film un peu trop haute qualite), que je pouvais quasi rien joue qui avait de la 3D (oui meme la boule en 3D qui se balade ramait).
      En fait simplement lancer Firefox avec trop d'onglet rendait mon ordi dur a utiliser (et je fermais toujours mes programmes avant de lancer un film). Ce n'etaient pas des configurations antiques. Je suis sur que si j'achetais un eeepc encore de nos jours, ce serait la meme chose.

      Maintenant j'ai un mega ordi i7, avec 8Go de Ram et du SSD. C'est sur, ca va beaucoup mieux. Il n'empeche que je me souviens avoir deja rencontre des problemes avec certains fichiers, meme avec cette machine de guerre (ou alors je melange mes souvenirs, c'est aussi possible. Globalement j'ai plus trop de probleme pour video/son). Et aussi essayer pour voir des jeux 3D, cela semble toujours une utopie sans carte 3D valable (j'ai une carte intel integree).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Qui a ce problème?

      Posté par . Évalué à 1.

      Sur un PC avec un proc Intel quadcore dernier cri, du SSD et de l'USB3 (64bits, 3.4.x, Gnome3, pulseaudio, mais sans systemd):
      En faisant un transfert SSD sur USB3 vers SSD interne, j'ai eu droit à des coupures de son… avec le CPU qui s'affole et qui monte à 100%, rendant le multitâche bureautique lent… classe en 2012…

      • [^] # Re: Qui a ce problème?

        Posté par (page perso) . Évalué à 7.

        J'ai constaté que la copie de fichiers via Nautilus ralentit fortement une machine. Par contre en ligne de commande, ça passe. Heureusement on ne pourra bientôt plus copier de fichiers via Gnome 3!

        http://devnewton.bci.im

        • [^] # Re: Qui a ce problème?

          Posté par . Évalué à 3.

          Avec dolphin c'est pareil, une grosse copie fait un peu tout ramer et quand il y a plein de fichier je trouve que rsync est plus performant.

  • # make -j$beaucoup

    Posté par . Évalué à 6.

    je n’ai, de base, aucun problème pour lire une vidéo quoique je fasse à côté.

    $ beaucoup=1024
    $ make -j$beaucoup >/dev/null 2>&1 &
    $ mplayer -fs mavideo-BD-RIP-1080p60-qui-bouffe-du-cpu.raw
    
    

    Là, à mon avis, et à moins d´avoir 1024 processeurs (ou cœurs) sur la babasse, la lecture de la vidéo va quand même saccader.

    Sinon : beaucoup=1048576 et relancer. Voire même : beaucoup='' et re-relancer.

    Disclaimer : do not try on production machine, be ready to hit the reset button, expect sluggishness. Killing polar bears and baby seals is an expected outcome. Use at your own risks.
    
    

    Hop,
    Moi.

    • [^] # Re: make -j$beaucoup

      Posté par . Évalué à 2. Dernière modification le 05/08/12 à 22:49.

      Je pense que le "de base" voulait dire "sans surcharger délibérément la machine". Je ne vois rien qui pourrait charger un desktop au point de faire saccader une vidéo (mis à part un logiciel planté). Même les gros traitement vidéo ne chargent pas autant le système qu'un make -j $trop. Le seul truc peut être, je sais pas ce que vaut l’ordonnanceur pour GPGPU. Lorsque je jouais avec Cuda, je pouvais pas regarder de vidéos en même temps, mais c'était il y a longtemps.

      Please do not feed the trolls

      • [^] # Re: make -j$beaucoup

        Posté par . Évalué à 4.

        Je pense que le "de base" voulait dire "sans surcharger délibérément la machine".

        Oui, mais il dit qu´il ne peut pas "surcharger sa machine pour faire des tests de cgroups".

        Là, avec ça, il peut.

        Hop,
        Moi.

    • [^] # Re: Hors sujet

      Posté par . Évalué à 4.

      Disclaimer : do not try on production machine, be ready to hit the reset button, expect sluggishness. Killing polar bears and baby seals is an expected outcome. Use at your own risks.

      Oh bah si c'est pour mettre la machine sur les genoux, un
      :(){ :|:& };:
      est efficace aussi, et plus rapide à taper.

      nb1 : c'est fou le nombre d'admins qui ne configurent pas leur limits.conf.

      nb2 : je m'en sers parfois comme démo cheap pour prouver à des septiques l'isolement des VMs en cas de plantage.

      *Sano*

      • [^] # Re: Hors sujet

        Posté par . Évalué à 2.

        Rappelons enfin aux sysadmins ici présent à ne pas faire de copier coller de cette chaine, ou au moins s'assurer que tous les buffers soient vidés avant de toucher à un terminal.

  • # Linux n'est pas prêt pour le desktop

    Posté par . Évalué à -6.

    Gouttegd, je ne peux t'aider car comme toi, je n'ai pas expérimenté de lenteur sous un bureau Linux en "vitesse de croisière".

    Par contre, sur un Windows 7 Michu Ready qu'on te vend de force, voir même un Windows 7 Ultimate™ craqué ou un Windows 7 professional du travail, il m'arrive très souvent d'avoir de la latence ou le reste des process qui ralenti quand je regarde une video haute définition ou charge un peu la bécane, sous windows, ça veut dire plus de 3 applications ouvertes dont une qui charge un peu niveau accès disque.

    ATTENTION, je ne nie pas qu'il y ait des soucis sous Linux Ubuntu, par exemple, je peux avoir Rhythmbox qui freeze après avoir joué N chansons mais malgré ce couac aléatoire (sans doute dû à GStreamer) j'ai une bien-bien meilleure expérience "Desktop" sous Ubuntu que sur n'importe quel Win 7 que j'ai sous la main.

    Ce qui m'agace c'est qu'on doit attendre l'arrivé de Valve pour recevoir le label certifié! :/

  • # Problème de CG

    Posté par . Évalué à 5.

    Sur mes trois portables, le seul qui saccade en lecture de vidéos, c'est le plus puissant avec un Core i7 et une Radeon HD5660 (driver libre). Les autres ont chacun une carte Intel avec soit un Atom soit un Centrino et n'ont aucun problème. Et tous sont sous Debian testing.

    Donc à mon avis, le gros problème vient souvent des pilotes graphiques, pas du CPU ou du système. Je me demande d'ailleurs si je ne vais pas revenir au pilote proprio parce que ça commence à me gaver. En tout cas, plus question d'acheter de l'ATI.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Problème de CG

      Posté par (page perso) . Évalué à 1.

      Sur un mac avec os x et une nvidia, il est arrivé que le pilote graphique me monopolise tout le système.

      Il suffisait que je fasse une action dans keynote (un powerpoint like mais bien), pour avoir un lag général de quelques milisecondes, avec le son qui coupe, et un gros crack à la reprise. Génial quand on doit déplacer un bloc pixel par pixel :)

      Envoyé depuis mon lapin.

    • [^] # Re: Problème de CG

      Posté par . Évalué à 3.

      Il y a quelques temps j'avais ce problème aussi. Il me fallait désactiver les effets dans kwin sous KDE pour lire correctement une vidéo. Avec les dernières versions de KDE (4.8), ce soucis à disparu, une vidéo en 720p passe bien… Peut-être une piste pour chez toi ?

    • [^] # Re: Problème de CG

      Posté par . Évalué à 2.

      Quelle version des pilotes libres as-tu (noyau & Mesa) ? Bien que ta carte ne soit pas "si" récente que ça, ça peut beaucoup changer.

      • [^] # Re: Problème de CG

        Posté par . Évalué à 2.

        C'est une Debian testing à jour avec un noyau experimental, donc :

        • Linux 3.4
        • Pilote 6.14.4
        • Mesa 8.0.3

        Je vois que la 6.14.6 est sortie entre temps. Je vais devoir attendre avant qu'elle n'intègre Debian, mais je n'y crois pas trop.

        En tout cas, les trois portables sont au même niveau de version donc ça ne peut venir que du pilote.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Problème de CG

          Posté par . Évalué à 3.

          Humpf en effet. Le 3.5 vient d'arriver dans experimental avec des améliorations particulières pour les Radeon 5k & plus, mais ce n'est pas gagné.

          • [^] # Re: Problème de CG

            Posté par . Évalué à 2.

            En effet, je n'avais pas vu la 3.5, je vais essayer ça. Merci.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Problème de CG

              Posté par . Évalué à 2.

              Pas de quoi, c'est d'aujourd'hui ou hier il me semble. N'hésite pas à préciser si ça aide.

  • # iowait

    Posté par . Évalué à 8.

    La seule manière vraiment reproductible de faire sauter une vidéo ou de l'audio que j'ai remarquée, c'est une bonne tempête d'IO, plus que la charge cpu. Et pourtant, mes machines sont pas spécialement des foudres de guerre.
    Tout à coup, au milieu d'une vidéo, on voit l'image qui s'arrête et le son qui continue(ou plus rarement l'inverse), puis tout stoppe quelques secondes redémarre et s'arrête sur un son joué en boucle sur une seconde.
    Quand ça arrive (arrivait, je fais un peu en sorte que ça n'arrive plus), le wm peut devenir super lent (changer de fenêtre prendre une minute, avec les redessins très longs), même la saisie clavier est difficile.
    Passer sur un VT, se logguer et lancer iotop (le tout peut prendre plusieurs minutes) montre le problème, mais pas forcément son origine (le processus qu'on voit faire des io peut être la victime qui est envoyée en swap).
    À ce que j'ai compris, il y a en gros 2 causes :
    - un processus avec une fuite mémoire qui crame de la mémoire et envoie tous les copains en swap en générant beaucoup d'io
    - une copie un peu longue sur un support lent (usb ou réseau)

    Ce qu'il se passe, c'est que les cgroups ne contrôlent pas (encore) les io, donc tout le monde peut se marcher sur les pieds.

    Donc non, pour moi, le scheduler cpu n'est pas(trop) un problème, à côté de ça.

    • [^] # Re: iowait

      Posté par . Évalué à 2.

      au niveau IO, il y eu des changement récemment sur la gestion d'un thread noyau par support au lieu d'un par programme (de mémoire). Cela permet de bien mieux gérer un périphérique qui devient libre par rapport à la gestion d'avant (et sauver des cycles cpu).

      "La première sécurité est la liberté"

    • [^] # Re: iowait

      Posté par (page perso) . Évalué à 3.

      J'ajouterai pour info qu'il existe également différents ordonnanceurs pour les I/O.

      debianport ~ # cat /sys/block/sda/queue/scheduler
      noop anticipatory deadline [cfq]

      Le 'scheduler' utilisé est entre crochets. On peut le changer par un simple 'echo':

      debianport ~ # echo 'deadline'> /sys/block/sda/queue/scheduler
      debianport ~ # cat /sys/block/sda/queue/scheduler
      noop anticipatory [deadline] cfq

      En outre on peut changer la priorité des entrées-sorties d'un processus (pour l'ordonnanceur cfq uniquement) grâce à ionice.

  • # Astuces

    Posté par . Évalué à 5.

    Il y a quelques astuces très intéressantes dans le journal et les commentaires. Personnellement ça pourrait m'intéresser pour autre chose que la vidéo (j'ai souvent 2 ou 3 processus lourds qui se marchent sur les pieds).

    Vous avez des docs pour la mise en place de ces solutions (cgroupes, ionice, etc)? Par exemple je me demande comment faire un groupe de processus système et que tous y aillent.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Astuces

      Posté par (page perso) . Évalué à 4.

      Vous avez des docs pour la mise en place de ces solutions (cgroupes, ionice, etc)?

      Pour ma part, j’ai utilisé :

      Par exemple je me demande comment faire un groupe de processus système et que tous y aillent.

      Normalement, si le paquet libcgroup (ou cgroup-bin sous Debian) est installé et les services cgconfig et cgred activés, c’est le comportement par défaut : cgconfig crée un cgroup sysdefault et cgred y envoit par défaut tous les processus.

    • [^] # Re: Astuces

      Posté par (page perso) . Évalué à 2.

      Qu'on me corrige si je dis une bêtise mais je crois que les I/O et les autres ressources des process (CPU, mémoire, etc) sont gérées par des ordonnanceurs différents (ex: cfq et group cpu scheduling) Je ne crois pas donc que les I/O puissent également être gérées par les cgroups.

      Sinon Red Hat a une doc très complète ici:
      http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/index.html

      • [^] # Re: Astuces

        Posté par (page perso) . Évalué à 3. Dernière modification le 07/08/12 à 15:28.

        Je ne crois pas donc que les I/O puissent également être gérées par les cgroups

        Si, les cgroups sont un mécanisme générique qui n’est ni lié ni restreint à l’ordonnanceur de tâche, on peut s’en servir pour gérer l’occupation du CPU (contrôleur cpu), les entrées/sorties disque (contrôleur blkio) et réseau (contrôleur net_prio), la mémoire (contrôleur memory), l’accès aux périphériques (contrôleur devices), etc.

        Dans ce journal, je proposais de s’en servir pour l’occupaation CPU uniquement, parce que je pensais que c’était le principal facteur du problème exposé, je n’avais pas pensé que les accès disques pouvaient aussi jouer un rôle.

        • [^] # Re: Astuces

          Posté par (page perso) . Évalué à 2.

          Merci pour ton complément de réponse. Mais est-ce que ça signifie qu'on peut créer un cgroup et définir son ordonnanceur d'I/O différemment ? Ça pourrait être intéressant dans pas mal de situations ça…
          Notamment lorsqu'on a des processus qui ne se servent que de périphs style mémoire flash/usb ou l'ordonnanceur Noop est supérieur à cfq ou à deadline.
          Merci d'avance si tu as le temps de me donner une réponse.

          • [^] # Re: Astuces

            Posté par (page perso) . Évalué à 2.

            Mais est-ce que ça signifie qu'on peut créer un cgroup et définir son ordonnanceur d'I/O différemment ?

            Apparemment non, en tout cas je n’ai rien vu de tel. Et il semble de plus que la répartition de bande passante entre cgroups, via le contrôleur blkio, n’est possible qu’avec l’ordonnanceur CFQ.

  • # Precise 64 bits

    Posté par (page perso) . Évalué à 2.

    Salut,

    J'avoue ma paresse à avoir suivi les récents devs et sur ce que sont précisément les cgroups.
    J'avoue la même paresse au sujet des upgrades qui surviennent sur mon laptop en precise 64 bits.
    Mais je découvre avec surprise qu'un petit "mount" m'affiche l'usage des cgroups sur toute un série de ressources.

    Je suppose que ceci est apparu soit par l'entremise des apt-get upgrade successifs, soit par l'install d'un logiciel, sans que je n'y ait porté attention.
    Je vous raconte ma vie pour afficher ma surprise par rapport à ce journal : en ubuntu precise, vu ce que je vois sur ma machine, je croyais que tout le monde utilisait désormais les c-groups ?

    Encore plus étonnant pour moi, mon autre laptop en precise 32 bits lui aussi régulièrement upgradé n'utilise pas les c-groups…
    La différence majeure entre les deux est que le 64 bits contient une install de kvm et ses copains : est-ce discriminant ?

    • [^] # Re: Precise 64 bits

      Posté par . Évalué à 1.

      Le paquet cgroup-lite doit être installé sur ton 64bits

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.