Journal Linux: une décennie de coeurs gaspillés

Posté par (page perso) . Licence CC by-sa
60
8
avr.
2016

D'aucuns pensaient que l'ordonnancement (scheduling) était un problème résolu ou presque. Linus Torvals disait en 2001:

And you have to realize that there are not very many
things that have aged as well as the scheduler. Which is
just another proof that scheduling is easy.

Vous devez réaliser que peu de choses ont aussi bien vieilli que l'ordonnanceur.
Ce qui constitue une preuve de plus que l'ordonnancement est facile.

L'implémentation pratique d'un algorithme pour les systèmes multi-coeurs est cependant loin d'être triviale. La publication qui donne lieu à ce journal The Linux Scheduler: a Decade of Wasted Cores
l'illustre sur plusieurs points. La parution de ce journal un vendredi est bien entendu une pure coïncidence.

En résumé, la problématique est que le coût de transfert d'un process vers un autre coeur est potentiellement élevé, et dépend entre autre de la structure des mémoires cache. L'agrégation des données de charge entre les coeurs/processeurs doit aussi être réfléchie, il y a un équilibre à trouver entre trop partager entre les coeurs et ralentir le système et risquer de prendre des décisions d'ordonnancement basées sur des informations partielles. Il y a donc recours à des heuristiques et optimisations qui ne fonctionnent pas dans tous les cas: dans la publication il est montré que certains coeurs sont inactifs pour de longues période alors que des processus prêts à tourner attendent ailleurs. L'article se lit bien et est agrémenté de citations de notre cher Linus qui n'a pas toujours raison…

  • # Energy waste is proportional.

    Posté par . Évalué à 0.

    +1 à main levée, comme je n'ai plus de droit de vote ; )

    • [^] # Re: Energy waste is proportional.

      Posté par . Évalué à 10.

      https://linuxfr.org/aide#aide-karma

      Depending on the time of day, the French go either way.

      • [^] # Re: Energy waste is proportional.

        Posté par . Évalué à -5.

        Pour pouvoir écrire un journal, dans le wiki ou sur la tribune, il faut avoir un karma supérieur strictement à 0 (sources journal, wiki, tribune).

        autant dire que c'est mort pour moi pour le moment :D
        Et bon bah, je ne te mettrais pas +1 pour contribuer à ton karma vu que je ne peux plus voter :=/

        J'aimerais bien connaitre ma valeur de karma.

        Pour en revenir sur le papier, on s'amuse beaucoup à lire les citations ;)
        Par contre la partie explicative de l’ordonnancement en multi-coeur nécessitera plus d'une re-lecture, donc au moins 3 lectures en ce qui me concerne.

  • # Ouai...

    Posté par . Évalué à 10.

    D'aucuns pensaient que l'ordonnancement (scheduling) était un problème résolu ou presque. Linus Torvals disait en 2001:

    Puis en 2007, le noyau a totalement changé de scheduler pour passer à CFS (les cgroups, LXC, Docker, systemd, ça parle à des gens ? ;) ) et c'était tellement limpide qu'il y toujours eu un concurrent de CFS : BFS (pour Brain Fuck Scheduler). D'après son maintenant, quand tu a moins de 16 cores son truc est mieux (j'en profite pour découvrir que c'est encore maintenu ce qui est cool :).

    J'ai pas lu l'article mais par rapport à ce que tu dis. Grosso modo le problème des schedulers, c'est qu'ils doivent prendre en un temps très réduit une décision sans pour autant avoir toutes les informations dont ils ont besoin à disposition. Le noyau a toujours (ou depuis très longtemps) eu de quoi interagir avec l'ordonnanceur depuis le userspace (avec cpuset par exemple), mais CFS via les cgroups a apporté beaucoup plus de finesse dans cela.

    Pour rappel 3 ans après sont introduction, on a eu une nouvelle option dans le noyau qui montrait bien l'intérêt de CFS : http://www.computerworld.com/article/2469655/desktop-apps/the-linux-desktop-may-soon-be-a-lot-faster.html

    Bref en 2001, il restait encore beaucoup à faire ! :)

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

    • [^] # However, they must be able to steal from the more loaded cores on other nodes.

      Posté par . Évalué à -9.

      Why is this not the case?
      Remember that to limit algorithmic complexity, the load
      balancing algorithm uses a hierarchical design. When a core
      attempts to steal work from another node, or, in other words,
      from another scheduling group, it does not examine the load
      of every core in that group, it only looks at the group’s
      average load (line 11 of Algorithm 1). If the average load
      of the victim scheduling group is greater than that of its
      own, it will attempt to steal from that group; otherwise it
      will not. This is the exact reason why in our situation the
      underloaded cores fail to steal from the overloaded cores
      on other nodes. They observe that the average load of the
      victim node’s scheduling group is not any greater than their
      own. The core trying to steal work runs on the same node
      as the high-load R thread; that thread skews up the average
      load for that node and conceals the fact that some cores are
      actually idle. At the same time, cores on the victim node,
      with roughly the same average load, have lots of waiting
      threads.

      • [^] # Re: However, they must be able to steal from the more loaded cores on other nodes.

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

        Même traduit automatiquement ça ne devient pas compréhensible en français ;-)

        Pourquoi est-ce pas le cas?
        Rappelez-vous que pour limiter la complexité algorithmique, la charge algorithme d'équilibrage utilise une conception hiérarchique. Quand un noyau les tentatives de voler le travail d'un autre noeud, ou, en d'autres termes, d'un autre groupe de planification, il ne porte pas sur la charge de chaque noyau de ce groupe, il ne regarde que le groupe de charge moyenne (ligne 11 de l'algorithme 1). Si la charge moyenne du groupe de planification de la victime est supérieure à celle de son propre, il va tenter de voler de ce groupe; sinon ne sera pas. Ceci est la raison exacte pour laquelle dans notre situation, la noyaux sous-charge ne parviennent pas à voler les noyaux surchargés sur d'autres nœuds. Ils observent que la charge moyenne de la victime noeuds groupe de planification est pas plus grande que leur posséder. Le noyau essayant de voler le travail fonctionne sur le même noeud le R-fil de charge élevée; ce fil biaise la moyenne charger pour ce noeud et cache le fait que certains noyaux sont effectivement ralenti. Dans le même temps, les noyaux sur le noeud victime, avec à peu près la même charge moyenne, ont beaucoup d'attente threads.

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

        • [^] # Re: However, they must be able to steal from the more loaded cores on other nodes.

          Posté par . Évalué à -6.

          oui, et puis je ne m'y tenterais pas. Le portage de certaines dénominations de la langue anglaise vers la langue française sont vraiment insupportable.

          Mon plus bel exemple étant celui ci

          Projects each element of an observable sequence into a new sequence of
          observable sequences by incorporating the element's index and then transforms
          an observable sequence of observable sequences into an observable sequence
          producing values only from the most recent observable sequence.

          tenter le en traduisant observable par sujet, vous allez voir c'est pas fun ; )

          Ceci dit, c'était surtout pour réagir à ceci, mais la citation était mal choisie.

          Le noyau a toujours (ou depuis très longtemps) eu de quoi interagir avec l'ordonnanceur depuis le userspace (avec cpuset par exemple), mais CFS via les cgroups a apporté beaucoup plus de finesse dans cela.

          Je saute aux conclusions (j'avoue je n'ai pas lu tous les bugs), le problème n'est pas le manque d'outils existant ou d'algo, mais leurs intégrations dans un système fiable et cohérent.

          All of these algorithms (le papier en cite plusieurs pour diverses optimisations) showed positive benefits, either in terms of performance or power, for some real applications. However, few of them were adopted in mainstream operating systems, mainly because it is not clear how to integrate all these ideas in scheduler safely.

          Pour réussir ce véritable défi, le papier préconise de commencer par se doter d'outils de visualisation.

          Another lesson we learned as a result of this work is the crucial importance of visualization tools. Understanding the root causes of the bugs we described would not have been possible without visualization of the execution events relevant to the problem.

          et le yakafonkon qui va bien pour aller plus loin

          What we need is to rethink the architecture of the scheduler, since it can no longer remain a small, compact and largely isolated part of the kernel. We now understand that rapid evolution of hardware that we are witnessing today will motivate more and more scheduler optimizations. The scheduler must be able to easily integrate them, and to have a way of reasoning about how to combine them. We envision a scheduler that is a collection of modules: the core module and optimization modules.

          lire aussi,

          There were algorithms that scheduled threads
          so as to minimize contention for shared caches, memory
          controllers and multithreaded CPU pipelines [8, 9, 24, 29,
          34, 42, 46]. There were algorithms that reduced commu-
          nication distance among threads sharing data [41] and de-
          termined the optimal number of cores to allocate to mul-
          tithreaded workloads [17]. There were algorithms that ad-
          dressed the scheduling of threads on asymmetric multicore
          CPUs [22, 35] and algorithms that integrated scheduling
          with the management of power and temperature [19]. Fi-
          nally, there were algorithms that managed the memory on
          NUMA systems, which was closely tied to how threads are
          being scheduled [7, 14, 18, 38], and algorithms that sched-
          uled threads to minimize communication latency on systems
          with an asymmetric interconnect

          si je ne m'abuses évidemment ! Plus évidemment encore, c'est avec joie je me prendrais d'autres -1 si je dit une bêtise. Vu que je suis déjà à -32 je n'ai plus peur de rien :p

          La question qui me reste en suspend étant celle ci, au départ, quels étaient les signes qui montraient une faiblesse de l'algo à cet endroit là ?
          Car si j'en suis le papier, il y a d'abord eu suspicion, puis création d'un outils de visualisation, puis correction, production de preuves et enfin théorisation.
          Ptet je l'ai loupé.

          • [^] # Re: However, they must be able to steal from the more loaded cores on other nodes.

            Posté par . Évalué à 6.

            Projects each element of an observable sequence into a new sequence of
            observable sequences by incorporating the element's index and then transforms
            an observable sequence of observable sequences into an observable sequence
            producing values only from the most recent observable sequence.

            tenter le en traduisant observable par sujet, vous allez voir c'est pas fun ; )

            Tricheur ! Ouh ! C'est la doc de Rx ! Observable est un nom propre dans ce contexte. C'est comme si tu voulais traduire Windows par fenêtre pour parler de l'OS ou Apple par pomme pour parler de la société aux ordinateurs blancs.

            M'étonne pas que tu sois à -32 avec des triches pareil ! ;)

            Ceci dit, c'était surtout pour réagir à ceci, mais la citation était mal choisie.

            Le noyau a toujours (ou depuis très longtemps) eu de quoi interagir avec l'ordonnanceur depuis le userspace (avec cpuset par exemple), mais CFS via les cgroups a apporté beaucoup plus de finesse dans cela.

            Je n'ai pas dis que c'était suffisant ou même parfait, j'ai dis que ça existait.

            Mais c'est un problème assez compliqué et il y a des débats houleux sur ces sujets en témoigne le gros débat qu'il y a eu sur la façon de gérer les cgroups (avec Google qui a des besoins particuliers pour Android et systemd qui veut devenir seul maître abord).

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

  • # Et Paf!

    Posté par (page perso) . Évalué à 2. Dernière modification le 08/04/16 à 10:31.

    Il fallait que ce journal tombe aujourd'hui, où j'obtiens un truc bizarre avec l'ordonnanceur:
    - musique de fond avec Clementine (sous KDE4 et à travers Pulseaudio), ça ne coupe jamais SAUF
    - si je tue la mémoire disponible (SWAP en remplissage à fond)
    - si je convertis des fichiers audio avec soundKonverter, même pour un seul fichier à la fois.

    C'est un bi-cœur, et il n'a aucun problème avec du stress -c 20. Alors quoi?

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

    • [^] # Re: Et Paf!

      Posté par . Évalué à 6.

      C'est un bi-cœur, et il n'a aucun problème avec du stress -c 20. Alors quoi?

      Je ne sais pas mais tu peux déjà essayer de lancer Clementine et soundKonverter dans 2 cgroups différents.

      Perso pour faire ça simplement,

      cgcreate -a barmic:barmic -t barmic:barmic -g "cpu:/clementin"
      #cgset -r cpu.shares=256 "clementin" si tu veux changer son temps de partage du CPU

      puis :

      cgexec -g "cpu:/clementin" clementine

      Par contre j'ai pas compris :

      si je tue la mémoire disponible (SWAP en remplissage à fond)

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

      • [^] # Re: Et Paf!

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

        Par contre j'ai pas compris : si je tue la mémoire disponible (SWAP en remplissage à fond)

        C'est juste que Firefox avec xdebug peut partir en vrille, mangeant toute la RAM disponible. Ça sature les io, mais là je comprends pourquoi. C'est avec soundKonverter que je ne comprends pas, car si je convertis en ligne de commande avec un pipe ça ne le fait pas. Peut-être une saturation du dbus?

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

    • [^] # Re: Et Paf!

      Posté par . Évalué à 5.

      "- si je convertis des fichiers audio avec soundKonverter, même pour un seul fichier à la fois."

      Contrairement à ce que l'on croit, le système disque peut introduire des latences sur les autres processus. Cela occupe de la bande passante mémoire, le contrôleur IO n'est pas forcément très rapide, etc…

      Je pense que c'est la même chose avec des cartes réseaux mais très rapide (10G ?)

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

    • [^] # Re: Et Paf!

      Posté par . Évalué à 2.

      Alors quoi?

      Alors merci Pulseaudio…

    • [^] # Re: Et Paf!

      Posté par . Évalué à 9.

      C'est pas avec BeOS que ce genre de malheur arriverait.

      BeOS le faisait il y a 15 ans !

    • [^] # Re: Et Paf!

      Posté par . Évalué à 5.

      Pour le coup je pense que c'est plutôt le scheduler d'I/O là qui a du mal.
      Et ça je le remarque aussi très souvent sur les disques mécaniques lents.

      • [^] # Re: Et Paf!

        Posté par . Évalué à 0.

        disques mécaniques lents.

        C'est pas un pléonasme ? ;-)

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # 2016, la majorité des programmes tournent toujours sur un coeur

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

    2016, la majorité des programmes tournent toujours sur un coeur.

    Par exemple, bunziper un gros fichier rends le premier a 100%.

    Il faut installer un lbzip2 pour avoir une version qui utilise plusieurs coeurs.

    Et c'est d'autant plus triste qu'un changement du scheduler dans le kernel ne changera strictement rien à cette situation.

    • [^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur

      Posté par . Évalué à 5.

      Une autre fonction importante du scheduler consiste à choisir le niveau d'endormissement des CPU. C'est aussi encore un grand sujet et ça évolue tout le temps avec les améliorations des CPU et ça impact directement les softs qui sont monothreadés.

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

    • [^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur

      Posté par . Évalué à -5.

      En passant, une question qui vient à l'esprit, est ce que ce n'est pas aussi un problème de format totalement inadapté à cette situation relativement nouvelle ?

      • [^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur

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

        Bien sûr. D'ailleurs xz pour pouvoir travailler en pipe de tar est aussi mono-cœur.

        Par contre p7zip tourne sur plusieurs cœurs, essaye 7z b.

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

        • [^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur

          Posté par . Évalué à 4.

          a.tar 278Mo, il s'agit d'un dépôt git

          time 7z a a.tar.7z a.tar
          real 0m50.126s
          user 2m13.483s
          sys 0m2.632s

          time xz -T 0 a.tar
          real 0m56.706s
          user 2m44.330s
          sys 0m1.092s

          ls -al a.tar.*
          175703485 a.tar.7z
          175622872 a.tar.xz

          Bon, 7z est un peu plus rapide, mais xz est multi-threadable aussi.
          Ça coince peut-être en pipe de tar, où il redevient mono-thread, mais bon, en mettant le -T 0 dans ton XZOPTS, l'utilisation de xz sans tar va être multi-coeur, et ses performances presque identiques à celles de 7z…

          Après on peut discuter de ça :
          time xz -T 1 a.tar
          real 2m16.947s
          user 2m16.357s
          sys 0m0.494s

          Où le temps processeur réel est significativement plus faible, donc a priori la consommation électrique, sachant qu'un processeur moderne sur un système moderne peut laisser les coeurs inactifs en idle, donc économiser du jus, de la chaleur, donc des ventilos, donc encore du jus.
          Si tu as du temps disponible, le multi-threading n'est pas forcément très écologique…

          Yth.

        • [^] # Re: 2016, la majorité des programmes tournent toujours sur un coeur

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

          Il faut surtout savoir si une programmation multi-coeur peut potentiellement être intéressante pour la problématique. Utiliser plusieurs cœurs c'est entre autre mettre des lock pour garder l'intégrité de certaines données partagées et ces derniers ont un coût.

          Dans le cas de la compression sans perte par exemple, il s'agit de calculer la fréquence des caractères et, dans le cas d'une compression LZ77 (ou dérivé), il s'agit de maintenir un dictionnaire de pattern pour obtenir les distances. L'accès à ces éléments (en écriture principalement) se fait presque à chaque caractère, il s'agirait donc de mettre un lock à chaque fois qu'on lit un caractère. Dans ce contexte, on peut facilement inférer qu'utiliser plusieurs cœurs pour un seul document n'est pas la bonne stratégie - l'idée ensuite qu'on puisse considérer qu'un processus puisse s'occuper de N caractère (et donc locker tout les N caractères) n'est pas envisageable puisque cela invaliderait les distances pour la compression LZ77. On peut toujours trouver des solutions mais qui ne ferait que ralentir l'algorithme en général avec des partages de contexte fastidieux.

          Là où l'on peut par contre utiliser le multi-coeur, c'est dès qu'il s'agit de compresser plusieurs documents indépendamment (et de merger ensuite les fréquences obtenues pour générer un arbre de huffman commun) - les distances seront alors limitées au document mais si on se place dans un ratio vitesse/taille, cela reste négligeable.

          Se placer dans une problématique multi-coeur de facto n'est pas toujours la bonne solution, il s'agit surtout de cibler le niveau d'atomicité de notre algorithme. Je sais pas si c'est vraiment le bon terme mais dans l'exemple, on peut considérer que chaque document peut être compressé séparément alors qu'on peut difficilement atomiser l'algorithme compressant un document en plusieurs petits algorithmes indépendants. On considère donc l'algorithme comme atomique mais pas ce qu'il compose.

          Il est donc normal de voir encore des logiciels mono-coeur car ils seront plus efficaces que si ont se forcé à ce qu'ils utilisent plusieurs cœurs. La problématique reste difficile est elle est au centre de certaines langages hauts niveaux qui souhaiterait abstraire la programmation parallèle. C'est à mettre en opposition au global lock présent dans le garbage collector (comme en Python, JavaScript ou encore OCaml).

          Malheureusement, avoir un garbage collector multi-coeur peut amener un coût non négligeable qui pourrait ralentir des programmes mono-coeur (pour assurer la validité des pointeurs entre garbage collector partagé et garbage collector spécifique au cœur utilisé) d'où la réticence de certains développeurs à vouloir absolument intégrer le multi-coeur dans certains langages (comme OCaml). Bien entendu, des efforts sont fait dans le bon sens pour éviter l'overhead imposé.

          Tout ça pour dire qu'on aura toujours des programmes mono-coeur :) !

  • # Tour d'horizon

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

    C'est vraiment là une question pertinente; elle est à l'origine du clash entre M.Dillon et le reste de la core-team de FreeBSD qui a conduit à la création de Dragon-fly BSD et de son Light Weight Kernel Threads.

    L'ordonnanceur actuel de FreeBSD, ULE, a été introduit dans la branche 5 puis activé dans la 7 pour améliorer le système.

    J'avais lu quelques réflexion là dessus dans les bouquins de A.S. Tanenbaum.
    Existe-t-il un tour d'horizon sur les solutions trouvées par les différents systèmes ?
    Une sorte de liste comparée avec avantages et inconvénients.

    D'ailleurs sait-on comment les autres non-libres le gère ? ( Windows, Mac, autre)

    • [^] # Re: Tour d'horizon

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

      elle est à l'origine du clash entre M.Dillon et le reste de la core-team de FreeBSD qui a conduit à la création de Dragon-fly BSD et de son Light Weight Kernel Threads.

      L'ordonnanceur actuel de FreeBSD, ULE, a été introduit dans la branche 5 puis activé dans la 7 pour améliorer le système.

      D'ailleurs, suite à cette introduction, M.Dillon aurait déclaré « maintenant c'est dans DragonflyBSD qu'il manque ULE ».

      • [^] # Re: Tour d'horizon

        Posté par . Évalué à 3.

        La zoophilie est répréhensible. Les modérateurs devraient faire quelque chose contre ce genre de commentaires !

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

    • [^] # Re: Tour d'horizon

      Posté par . Évalué à 4.

      D'ailleurs sait-on comment les autres non-libres le gère ? ( Windows, Mac, autre)

      Vu comment c'est la misère pour tester ça sur un système données, le tester sur des systèmes différents doit être une enfer. Sans compter la complexité des profiles d'utilisation (par exemple avoir un lecteur audio et/ou un navigateur qui tourne en permanence peut être le genre de choses à prendre en compte par le scheduler). On devrait pouvoir avec Linux et les *BSD construire des systèmes minimalistes qui sont à peu prêt reproductibles.

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

      • [^] # Re: Tour d'horizon

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

        D'ailleurs sait-on comment les autres non-libres le gère ?

        Vu comment c'est la misère pour tester ça sur un système données,

        Sans le tester, est-ce que dans un premier temps, ce serait a minima documenté quelque part ?

  • # Le scheduler, il est a l'ouest !

    Posté par . Évalué à 6.

    Clairement le scheduler du noyau Linux a plus d'un probleme. Un des sujets non aborde dans l'article, qui est tres interressant. C'est les problemes de consommation d'energie et de scheduling lie a cela. Typiquement sur les taches interactives fonctionnant avec un device sur batterie, le scheduler est globalement toujours faux.

    Le principe du scheduler est de regarder le passe d'une tache pour en deviner son usage futur. Le probleme des taches interactives, c'est que par design le process principal fait un peu de tout a une frequence eleve (Hop, une IO, un peu de CPU bound pour calculer le nouveau layout, puis un peu de memory bound pour regarder si il y a des trucs a dessigner, …). Il devient assez evident que ce qu'une tache a fait dans le passe aide peu.

    La solution evidente, c'est de creer plusieurs process/thread qui chacun doit faire un seul truc. Meme si ils ne sont pas execute en parallele et si ils consomment plus de RAM, au final, le noyau devrait etre capable de scheduler tout ca de maniere plus efficace… Sauf que non, pour tout un tas detail, qu'on peut resumer a la non integration de cpufreq et cpuidle dans le scheduler, le noyau est incapable d'utiliser les ressources du materiel de maniere optimal. On se retrouve alors avec des gros hack pas beau. Comme par exemple sur certain telephone ou un process en tache de fond regarde quel est l'application active et change les parametres de frequence et du nombre de CPU en fonctionnement pour avoir un resultat un peu plus optimal… Gros hack, franchement pas terrible.

    Tout ca pour dire que sans le boulot en court du scheduler energy aware, et bien, on a encore de la marge… Oh, et bien entendu, l'user space doit aussi s'adapter ! On a encore du boulot pour quelques annees…

  • # [HS] Titre très romantique

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

    « Linux: une décennie de cœurs gaspillés », ça pourrait donner aussi pour un prochain journal « Linux: des cœurs à prendre ».

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # Absence de suite de tests ?

    Posté par . Évalué à 2.

    Ce qui frappe ici, c'est qu'il ne semble pas y avoir de procédure de test automatisé de l'ordonnanceur (avec de l'instrumentation pour simuler une configuration matérielle et une certaine succession d'appels de tâches) et que toute expérimentation doive passer par l'exécution réelle, sur un matériel réel, de tâches réelles en temps réel.

    Cela empêche aussi de tester sérieusement les régressions, à part en se reposant sur la communauté, ce qui est tout de même très hasardeux.

Suivre le flux des commentaires

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