Journal Rah nice && cgroups

Posté par  . Licence CC By‑SA.
Étiquettes :
14
16
mai
2012

Grande découverte en essayant Mageia 2 RC. On ne peut plus se suffire de lancer un truc lourd avec nice pour pas qu'il fasse ramer le reste!

Exemple : lancer dans 3 consoles 7z b , nice -20 7z b et top.
Les deux instances de 7z ont droit à 50% de CPU chacune. Par contre, si on les lance dans une seule console :

(nice -20 7z b &);(7z b &);top

Ils se partagent correctement : 90%/10% environ. Mais alors, comment lancer un service en arrière plan qui ne bouffe pas 50% du CPU?

Merci aux rois du cgroup, puisque je suppose que ça vient de cette belle évolution qui permet à Linus de regarder un film en faisant make -j48.

  • # Non, définitivement

    Posté par  . Évalué à 5.

    "On ne peut plus se suffire de lancer un truc lourd avec nice pour pas qu'il fasse ramer le reste" je ne comprends pas cette phrase.

    Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

    • [^] # Re: Non, définitivement

      Posté par  . Évalué à 0.

      ben "man nice"

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Non, définitivement

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 16 mai 2012 à 17:46.

        man ironie

        $ echo "On ne peut plus se suffire de lancer un truc lourd avec nice pour pas qu'il fasse ramer le reste" < gcc -x Français --pedantic -o PostLinuxFr
Syntax Error Try "Il ne suffit plus de lancer nice sur un truc lourd pour qu'il ne fasse plus ramer le reste" instead

      • [^] # Re: Non, définitivement

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 16 mai 2012 à 18:05.

        ben "man nice"

        Justement tu devrais le relire parce que nice -20 pour éviter de faire ramer ta bécane, heu comment dire… ou alors je n'ai pas non plus compris ton message. Je devrais peut-être essayer un
        $ apropos zino

        Ou sinon: CGROUP_SCHED=n

        • [^] # Re: Non, définitivement

          Posté par  . Évalué à 1.

          Ah okokok…. en fait c'est pas nice moins vingt, mais nice tiret vingt. Ça ajoute 20 à la valeur par défaut!

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Documentation

    Posté par  . Évalué à 2.

    Voir ici

    J'ai essayé vite fait avec un groupe à 100 cpu share et un à 900.

    100 shares:

    Dict        Compressing          |        Decompressing
      Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
       KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS

22:    2281    91   2430   2219  |    30548   110   2512   2756
23:    2684   113   2424   2735  |    39540   145   2493   3618
24:    3412   148   2483   3669  |   108073   391   2562  10026
25:    8092   348   2654   9239  |   105097   388   2548   9883
----------------------------------------------------------------
Avr:          175   2498   4465               259   2528   6571
Tot:          217   2513   5518

    900 shares:

    Dict        Compressing          |        Decompressing
      Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
       KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS

22:    7785   299   2537   7573  |    92630   326   2565   8357
23:    5872   232   2580   5983  |    88638   316   2568   8111
24:    6840   284   2591   7355  |    91305   332   2549   8470
25:    5969   259   2632   6815  |    90866   337   2534   8545
----------------------------------------------------------------
Avr:          268   2585   6932               328   2554   8371
Tot:          298   2569   7651

    • [^] # Re: Documentation

      Posté par  . Évalué à 2.

      J'y suis passé en fouillant, mais c'est pas concluant : même avec 2 shares, mon processus de fond arrive à prendre 30% de cpu sur mon mono-processeur. C'est sûr qu'avec un tri-cpu comme le tien ça se sent même pas, mais c'est pareil : 100% environ et 300% respectivement.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Documentation

        Posté par  . Évalué à 3.

        Quelques précisions pour comprendre la mécanique des cgroups :
        - la valeur dans cpu.shares est un poids attribué au process (normalisé à 1024) lors de l'attribution de temps sur un core ; Si tu lances deux benchs dans deux cgroups différents sur un même core, tu verras la répartition souhaitée, si tu les mets sur deux core ils mangeront chacun de leur côté.
        - Tu peux contrôler l'affinité, c'est à dire le core sur lequel réside un process, en restreignant les core accessibles grâce à cpu.cpus ; Cela permet par exemple de garantir que certains core restent disponibles.
        - Enfin l'attribution du temps n'a de sens que si le process en demande ; Si celui-ci est bloqué dans une IO il n'en recevra pas même si il a un poids maximum.

        Le cgroup cpu faut vraiment expérimenter un moment pour comprendre. :)

        • [^] # Re: Documentation

          Posté par  . Évalué à 6.

          Cette mécanique est exactement celle permise avec la priorisation nice depuis aussi longtemps que je connais linux. cgroups apporte surtout la possibilité de grouper les taĉhes, pour que 48 processus en basse priorité ne finissent pas par faire saccader un processus unique genre lecteur vidéo en priorité normale. L'idée est que chaque groupe de processus est vu comme un seul droit processeur.

          Mais en fait, j'ai fini par trouver comment faire fonctionner le nice "normalement" :

          echo "kernel.sched_autogroup_enabled = 0" >> /etc/sysctl.conf
sysctl -p

          https://bugzilla.redhat.com/show_bug.cgi?id=721416

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # schedtool et ionice

    Posté par  . Évalué à 2.

    Tu peux essayer du cote de schedtool et ionice
    exemple: schedtool -D -n 19 -e ionice -c 3 '7z b'

Suivre le flux des commentaires

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