mardi 30 juin

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[15] Open Arena 0.7 disponible le 07/07/07 !
[14] Sortie d'Amaya 9.55
[11] Sortie de FreedroidRPG 0.10.2
[54] Sortie de sesam viewer
[18] Eclipse 3.3 (Europa) est sorti
[12] Sortie d'OpenSceneGraph 2.0
[17] Open Motif 2.3 : Anticrénelage, unicode et plus…
[14] TestDisk & PhotoRec 6.7 disponibles!
[43] Sortie de digiKam 0.9.2
[12] Scorched 3D : projet du mois de mai sur SourceForge.net

Liens connexes

Les nouveautés de Linux 2.6.22 (2685 hits)
Le bilan des ajouts 1 (687 hits)
Le bilan des ajouts 2 (549 hits)
Les articles du symposium Linux 2007 (259 hits)

Dépêche modérée par

Oumph

Dépêche éditée par

Logiciel : Sortie du noyau Linux 2.6.22

Posté par patrick_g (page perso, ). Modéré le 09 juillet 2007.

La dernière version du noyau Linux stable est téléchargeable sur les serveurs du site kernel.org. Cette version 2.6.22 a suivi le processus normal et maintenant archi-classique des release candidate :

La version RC-1 est apparue juste quinze jours après la sortie du noyau stable précédent. Linus a reconnu que le noyau 2.6.21 avait connu une gestation difficile et il espère que cette RC-1 annonce un progrès sur ce plan (traduction libre): «Je pense (et j'espère) que cela ne va pas être aussi douloureux que les gros changements du code des timers du noyau 2.6.21. Bien qu'il y ait ici aussi des changements importants (...) cela semble assez solide.»
La version RC-2 a continué sur cette voie d'une version solide et bien debuggée et Linus a rappelé la règle qui interdit d'ajouter des nouvelles fonctions à ce stade du développement (traduction libre): «N'essayez même pas d'envoyer autre chose que des corrections de bugs ! Je pense que la situation actuelle semble raisonnablement bonne pour le noyau 2.6.22.»
La sortie de la version RC-3 le 25 mai a donné l'occasion à Linus d'écrire un de ses petits bijoux humoristiques dont il a le secret. Il a lancé un appel pour que les gens téléchargent et testent cette RC-3 au lieu d'aller à la plage (traduction libre): «Nous sommes vendredi soir et les USA se préparent à un long week-end de trois jours, souvent considéré ici comme le début officiel de l'été. Donc que peut faire un nerd blanc comme un bidet ? Vous ne pouvez pas aller à la plage parce que les gens normaux vont rigoler en vous voyant et vont vous jeter du sable à la figure. Mais vous _pouvez_ faire quelque chose : vous pouvez télécharger le dernier noyau RC-3 et sourire d'un air suffisant en sachant que vous faites tourner la toute dernière merveille sur votre machine. Et tout d'un coup, cela n'a plus d'importance que ce soit l'été parce que vous pouvez rester dans votre sous-sol aux stores fermés à vous faire bronzer à la chaude lumière de votre écran LCD plutôt qu'à la dure lumière du jour. Donc ne vous inquiétez plus de ces dangereux rayons ultra-violets et prenez votre vitamine D sous la forme prévue par Dieu (et l'industrie pharmaceutique) : des petites pilules facilement avalables. Les plages sont très surfaites de toute manière, le sable s'introduit dans le ventilateur des ordinateurs portables et en un clin d'oeil plus rien ne fonctionne.
Puissiez vous avoir un bel été.»
La version RC-4 s'est contentée de corriger divers bugs et régressions et, dix jours plus tard, Linus s'est félicité d'avoir trouvé le temps de sortir la RC-5 en dépit de la monstrueuse flame-war GPLv2/GPLv3 ayant eu lieu sur la liste de diffusion.
Le 24 juin est apparue la -RC6 et le premier juillet la -RC7 qui semble satisfaire Linus (traduction libre): «Nous devrions être dans une très bonne situation. Le flot des patchs a vraiment ralenti et la liste de régression s'est beaucoup réduite.»
Enfin la version finale a été annoncée le dimanche 8 juillet et Linus s'est interrogé dans son courriel pour savoir si il était vraiment nécessaire de publier une liste complète des changements (un gros fichier de plus d'une centaine de milliers de lignes) alors que presque tout le monde utilise directement le gestionnaire de code source Git pour consulter cette liste. C'est donc sans doute la dernière fois que ce fichier récapitulatif des changements (changelog) sera publié séparément.

Les nouveautés de Linux 2.6.22 (2685 hits)
Le bilan des ajouts 1 (687 hits)
Le bilan des ajouts 2 (549 hits)
Les articles du symposium Linux 2007 (259 hits)

> Lire la suite (84 commentaires, moyenne: 4,3). [dépêche : 14696 caractères]

Le noyau 2.6.22 inclut une toute nouvelle couche wifi plus propre et plus performante. Elle a été initialement écrite par la société Devicescape (sous le nom d'Advanced Datapath Driver) avant d'être libérée en mai 2006 et adaptée par les hackers Linux au cours de ces derniers mois. Parmi les progrès, on note une implémentation complètement intégrée du WEP, du WPA, du couplage (bridging) des canaux, de la qualité de service (avec priorisation de la voix sur IP), du support 802.11g, du code de debugging...etc
Auparavant l'ancienne couche wifi était assez "sale" et de nombreux pilotes de cartes avaient réécrit certaines fonctions dans leur coin au lieu d'utiliser la couche générique du noyau. La nouvelle couche Devicescape étant bien plus complète et propre, cela va permettre d'adapter tous ces pilotes pour éviter au maximum la duplication du code et simplifier l'écriture des nouveaux pilotes.
On trouve également une couche Firewire complètement réécrite afin d'avoir un code plus petit, plus simple et plus maintenable, tout en conservant la compatibilité au maximum avec l'existant. L'API a été adaptée et le code passe de plus de 30000 ligne pour l'ancienne couche à moins de 8000 lignes dans cette nouvelle couche Firewire. Les quatre interfaces existantes pour les programmes en espace utilisateur (userspace ABI) ont fusionné afin de laisser place à une seule interface améliorée (la compatibilité est tout de même maintenue grâce aux bibliothèques libraw1394 et libdc1394).
Le mécanisme eventfd de notification des évènements est inclus dans cette version 2.6.22. Cet ajout est la conclusion d'une longue controverse et un exemple quasi-parfait du mode de développement hautement compétitif qui caractérise le noyau Linux. En ce sens cet épisode mérite que l'on s'y arrête quelque peu.
En décembre 2006, la situation semblait claire puisque le mécanisme générique proposé par Evgeniy Polyakov, Kevent, semblait la solution qui allait s'imposer. Il en était à sa vingt-sixième version car les développeurs voulaient prendre tout leur temps avant d'introduire une nouvelle API qu'il faudra maintenir indéfiniment. En dépit de cette prudence, on pouvait penser que l'inclusion dans la branche principale n'était qu'une question de maturation, d'autant que kevent avait reçu le soutien résolu d'Ulrich Drepper, le mainteneur de GlibC. Pourtant, Davide Libenzi ne l'entendait pas de cette oreille et il a proposé une autre solution, eventfd, basée uniquement sur des descripteurs de fichiers (file descriptors) et qui évite d'introduire une nouvelle API. Cette stratégie nécessite la création des appels systèmes signalfd et timerfd et, si elle sacrifie la "généricité" de kevent, elle est plus simple et plus UNIX dans l'âme (car basée sur la philosophie du "tout est fichier"). Avec eventfd, on peut donc continuer à utiliser read(), select() et poll() comme on le faisait auparavant.
Après des échanges enflammés sur la liste de diffusion du noyau et une argumentation très tranchée d'Ulrich Drepper en faveur de kevent, l'opinion majoritaire penchait néanmoins pour eventfd quand un nouveau concurrent, pollfs, est apparu au dernier moment. Son auteur, Davi Arnaut voulait mettre tout le monde d'accord mais son code a été durement critiqué et il n'a pas changé fondamentalement la donne. Après un dernier baroud d'honneur d'Ulrich Drepper le mécanisme de notification eventfd a finalement été introduit dans le noyau 2.6.22. La communauté Linux a donc fait le choix d'un outil simple à l'inverse, par exemple, de FreeBSD qui a privilégié, avec kqueue, le caractère très générique du fonctionnement au prix d'une plus grande complexité.
Continuant son combat pour un support aussi universel que possible, le noyau Linux accueille une nouvelle architecture de processeur. Blackfin est un microprocesseur à architecture RISC développé par Intel et Analog Devices, Inc (ADI) pour le marché de l'embarqué. C'est un processeur hybride (mi-CPU, mi-DSP) qui fait le pari du support complet sous Linux afin d'élargir son marché. Un site web a été mis sur pieds afin de centraliser toutes les ressources relatives à Linux et au logiciel libre.
Une partie importante du noyau Linux est son allocateur de mémoire (qui s'occupe de garder en cache de nombreux objets de différentes taille afin de permettre d'allouer la mémoire de façon efficace et rapide). Cet allocateur se nomme SLAB (il existe également une autre version, nommée SLOB, pour l'embarqué) et son code est complexe au point de décourager les contributions. La version 2.6.22 introduit un tout nouvel allocateur de mémoire (portant le nom poétique de SLUB) dont le code est beaucoup plus simple tout en étant plus performant (de 5 à 10%).
Ce projet a été lancé par la société SGI afin d'améliorer le rendement de ses superordinateurs comportant plus de mille processeurs. En effet elle s'est aperçue que SLAB engloutissait sans raison plusieurs gigaoctets de mémoire dans cette configuration extrême et a donc décidé de remédier une bonne fois pour toute à ces défauts en créant un nouvel allocateur plus efficace.
Par défaut, SLUB n'est pas activé (c'est une option lors de la compilation) mais sa présence dans la branche principale du noyau va permettre d'avoir de nombreux retours d'expérience et il a vocation à remplacer complètement SLAB à brève échéance.
UBI (Unsorted Block Images) est un tout nouvel outil présent dans cette version de Linux et qui permet de gérer les périphériques à base de mémoire NAND flash. C'est en quelque sorte un équivalent de LVM mais spécialisé dans la mémoire flash (LVM maps logical sector numbers to physical HDD sector numbers, UBI maps logical eraseblocks to physical eraseblocks).
Il permet la répartition des écritures sur toute la mémoire et il tient compte des blocs mémoire défectueux. Il gère également la création de volumes UBI qui peuvent être dynamiquement créés, re-dimensionnés ou supprimés. Un fichier PDF complet sur la conception d'UBI est disponible ici.
L'ordonnanceur CFQ (Complete Fair Queuing) qui s'occupe de gérer les entrées/sorties a été largement amélioré dans la nouvelle version du noyau Linux. Il peut maintenant détecter des processus qui coopérent entre eux ce qui lui permet de choisir la meilleure queue en attente. De plus Jens Axboe, son mainteneur principal, a choisi de s'inspirer de CFS, le tout nouvel ordonnanceur des processus actuellement développé par Ingo Molnar. L'idée principale est d'abandonner les listes triées par niveau de priorité (linked list per priority level for sorting and service uses) afin d'opter pour des arbres de recherches (rbtree of cfq_queue's, sorted by when to service them). Le concept est donc plus naturel et le fonctionnement de l'ordonnanceur est plus rapide.
Enfin le code de CFQ code a été simplifié en le purgeant d'une bonne partie des fonctions n'étant plus utiles.
L'interface utimensat a été ajoutée afin de permettre une précision du niveau de la nanoseconde dans les timestamps des systèmes de fichiers. Jusqu'ici l'interface utimes ne proposait qu'une précision limitée à la microseconde.
Le support des sous-types de systèmes de fichiers a été introduit dans le nouveau noyau Linux. Il permet de distinguer facilement les divers système de fichiers en espace utilisateur (basés sur FUSE). Ainsi, alors qu'auparavant le noyau ne faisait pas la différence et qu'il était difficile de spécifier le système de fichier utilisé dans son fstab, on peut maintenant mettre une mention bien plus explicite (par exemple "fuse.sshfs").
Dans la perspective d'une refonte future du code pour obtenir plus de stabilité et de rapidité, les fonctions d'hibernation (suspend to disk) et de veille (suspend to RAM) ont été séparés. Cela va permettre d'analyser plus finement les spécificités de chacune des fonctions et de les optimiser séparément.
Dans le domaine des réseaux TCP de nouveaux algorithmes de gestion des problèmes de congestion ont étés introduits. On note l'implémentation de YeAH-TCP et celle de TCP-Illinois.
Ces deux algorithmes sont spécialisés dans les réseaux à très grande vitesse (In some scenarios, TCP can only utilize less than 10% of network capacity. So a more efficient modification to TCP, which is called high sped TCP variant by researchers in this area, is needed in high speed networks).
Comme d'habitude un grand nombre de pilotes ont été ajoutés ou améliorés dans ce nouveau noyau Linux (par exemple le pilote IVTV qui permet le support des cartes TunerTV + compression MPEG de marque Connexant) et une multitude d'autres modifications ont trouvé leur chemin. Comme il en a pris l'habitude le site Linux Weekly News propose un article faisant le bilan complet sur les contributeurs de cette version. On peut y lire que la différence entre le noyau 2.6.22 et son prédécesseur immédiat est de 6000 patchs (écrits par 885 développeurs différents) ce qui représente 494000 lignes de code ajoutées et 241000 supprimées.

Si on se tourne vers le futur pour deviner ce que contiendront les versions à venir du noyau on peut regarder du coté d'utrace. C'est un remplaçant du système ptrace qui garde la même interface pour les programmes en espace utilisateur mais qui propose des fonctions bien plus riches). Ces divers outils de tracing fournissent au processus parent un moyen de contrôler l'exécution d'un autre processus afin de faciliter le débogage (cet article détaillé fait le point sur les outils de tracing pour Linux).
Le travail sur le système de fichier de nouvelle génération Ext4 se poursuit et la liste des nouvelles fonctionnalités est alléchante (voir aussi ce fichier pdf issu du symposium Linux d'Ottawa).
Le patch permettant d'implémenter la fonction de lecture spéculative à la demande (On-demand readahead) continue sa maturation. Cette fonction de lecture spéculative, qui existe depuis longtemps, autorise le chargement à l'avance du contenu d'un fichier que le noyau est en train de lire afin de pouvoir fournir les données plus rapidement aux applications. La nouveauté de ce patch réside bien entendu dans le "à la demande" qui permet d'avoir un code plus simple et plus flexible (ici aussi un papier du symposium Linux est disponible).
Le système de fichier spécialisé dans la mémoire Flash (LogFS) est également développé très activement dans la perspective de l'explosion imminente des disques durs de type SSD. LogFS est basé sur l'idée que les systèmes de fichiers classiques sont conçus principalement pour des disques magnétiques alors que les disques flash ne nécessitent pas tout le code extrêmement complexe qui tente d'éviter la fragmentation des fichiers. L'approche suivie est donc basée sur une écriture séquentielle des données (log-structured approach) qui, et c'est ce qui constitue la grande différence avec JFFS2, ne nécessite pas de scan complet du volume au montage. Comme un système classique toute la structure est donc gardée en mémoire directement dans le disque ce qui accélère considérablement le mount (sur un système OLPC on passe de 3,3 secondes sous JFFS2 à 60 millisecondes avec LogFS).
Enfin le nouvel ordonnanceur CFS d'Ingo Molnar (évoqué lors de la dépêche sur le noyau 2.6.21) en est à sa dix-neuvième version et le temps de l'inclusion dans la branche principale approche à grands pas !

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Bravo !

Posté par liberforce (Jabber id, page perso, ) le 09/07/2007 à 08:01. (lien). Évalué à 10.

News très claire et très bien rédigée, il fallait bien ça vu les nouveautés dont regorge à chaque version le noyau !

[^]Re: Bravo !

Posté par Guillaume CASTAGNINO (page perso, ) le 09/07/2007 à 08:26. (lien). Évalué à 10.
Oui Bravo !
Complet, avec tous les pointeurs sur les divers éléments cités...
Une dépêche de très grande qualité
Merci !

[^]Re: Bravo !

Posté par reno () le 09/07/2007 à 08:40. (lien). Évalué à 10.
Tout pareil: bravo!

J'ai eu l'impression de lire LWN!

[^]Re: Bravo !

Posté par Ludovic F (Jabber id, page perso, ) le 09/07/2007 à 11:44. (lien). Évalué à 6.
Tout simplement excellent.

Merci à l'auteur !
- [+] [^]Re: Bravo !
  
  Posté par H_francis () le 09/07/2007 à 17:41. (lien). Évalué à -1.
  
  #include <stdio.h>
  
  void affiche_bravo(void);
  
  int main(void)
  {
  affiche_bravo();
  return 0;
  }
  
  void affiche_bravo(void)
  {
  puts("Bravo! Tres belle news! Felicitation!");
  affiche_bravo();
  }
  
  Mpf.
  - [^]Re: Bravo !
    
    Posté par IsNotGood () le 09/07/2007 à 17:49. (lien). Évalué à 1.
    Évite les débordements dans tes commentaires.
    - [^]Re: Bravo !
      
      Posté par H_francis () le 09/07/2007 à 18:10. (lien). Évalué à 0.
      on sait jamais ça peut toujours servir.

[^]Re: Bravo !

Posté par NickNolte () le 09/07/2007 à 23:03. (lien). Évalué à 5.
Impeccable, quel plaisir de lecture et tout en francais (excepte 2,3 cas et les noms "propres" en anglais evidement).
Complet, clair et accessible, bravo.

Bon, Patrick_g, tu dois comprendre que c'est foutu pour toi... tu as la responsabilite, a present de presenter chaque nouvelle mouture du noyau nunux avec cette meme qualite. :)

Merci
- [^]Re: Bravo !
  
  Posté par patrick_g (page perso, ) le 10/07/2007 à 08:18. (lien). Évalué à 10.
  >>> Bon, Patrick_g, tu dois comprendre que c'est foutu pour toi...
  
  Bah j'ai regardé l'historique du site et je vois que j'ai écopé d'une condamnation longue sans remise de peine ;-)
  C'est vrai qu'au fil du temps ces news kernel ont tendance à s'allonger démesurément :
  
  2.6.13 => http://linuxfr.org/2005/08/29/19485.html (article de 1644 caractères).
  
  2.6.18 => http://linuxfr.org/2006/09/20/21352.html (article de 2493 caractères).
  
  2.6.19 => http://linuxfr.org/2006/11/30/21677.html (article de 6580 caractères).
  
  2.6.20 => http://linuxfr.org/2007/02/05/21986.html (article de 6764 caractères).
  
  2.6.21 => http://linuxfr.org/2007/04/26/22398.html (article de 9446 caractères).
  
  2.6.22 => http://linuxfr.org/2007/07/09/22676.html (article de 14910 caractères).
  
  Je pense qu'entre 10000 et 15000 caractères (en tout) c'est la bonne longueur pour évoquer la saga des -RC et détailler un peu les nouveautés. Je vais essayer de m'y tenir à l'avenir.

Merci !

Posté par Neilink () le 09/07/2007 à 08:09. (lien). Évalué à 10.

Merci beaucoup pour cet article, c'est toujours aussi passionnant de suivre l'évolution du noyau :)

[^]Re: Merci !

Posté par patrick_g (page perso, ) le 09/07/2007 à 10:07. (lien). Évalué à 10.
Et merci beaucoup aux relecteurs/modéros qui ont bien amélioré la news ces 10 derniers jours (avec un merci particulier pour baud123 qui a traduit la prose de Linus avec beaucoup plus de talent que moi ;-)
- [^]Re: Merci !
  
  Posté par baud123 (Jabber id, page perso, ) le 09/07/2007 à 10:34. (lien). Évalué à 7.
  le gros du boulot était fait quand même :D, un peu de wikipédification, Floxy pour ajouter du gras et revoir les ul/li et sbon.
  
  bwalé départ pour les RMLL, j'espère voir Alan Cox.

Merci

Posté par polytan () le 09/07/2007 à 08:11. (lien). Évalué à 9.

Merci beaucoup pour cette dépêche aussi riche et complète !

erreur lien

Posté par Noël Dubray (page perso, ) le 09/07/2007 à 08:26. (lien). Évalué à 1.

le lien correspondant au texte "802.11g" mene à de la voix sur IP. Je propose http://fr.wikipedia.org/wiki/802.11 à la place, ou la page en anglais qui est plus complète http://en.wikipedia.org/wiki/802.11 .

Fast forward

Posté par patrick_g (page perso, ) le 09/07/2007 à 08:30. (lien). Évalué à 10.

>>> Comme il en a pris l'habitude le site Linux Weekly News propose un article faisant le bilan complet sur les contributeurs de cette version.

A propos d'analyse du développement de Linux il y a un article extrêmement intéressant parmi ceux du dernier symposium => https://ols2006.108.redhat.com/2007/Reprints/kroah-hartman-R(...)
Le kernel hacker Greg Kroah-Hartman s'est servi du logiciel développé par Linux Weekly News (gitdm) pour analyser statistiquement les évolutions du noyau sur une période de près de deux ans et demi (du kernel 2.6.11 au kernel 2.6.21).
Je vous invite à lire cet article car il est bourré d'informations passionnantes.
Juste à titre d'exemple :

Entre la release du noyau 2.6.11 et celle du 2.6.21 il s'est écoulé 852 jours. Sur cette période le diff en nombre de patchs est de 59164. Une simple division donne donc le chiffre ahurissant de 2.89 patchs par heure pendant deux ans et demi (24 heures sur 24 et sept jours sur sept) !
En nombre de ligne de code c'est plus de 85 lignes de code noyau par heure pendant deux ans et demi...simplement hallucinant.

Mode optimiste on/
Et après on se demande pourquoi Microsoft ne peux pas suivre le rythme !
Mode optimiste off/

[^]Re: Fast forward

Posté par windu.2b (Jabber id, page perso, ) le 09/07/2007 à 08:49. (lien). Évalué à 2.
Merci pour ces chiffres...
Avec ceux de la news ("On peut y lire que la différence entre le noyau 2.6.22 et son prédécesseur immédiat est de 6000 patchs (écrits par 885 développeurs différents) ce qui représente 494000 lignes de code ajoutées et 241000 supprimées."), ça donne une idée de l'ampleur du travail effectué par tous ces travailleurs de l'ombre!

Un grand bravo à tous ceux-là, parce que franchement je suis sur le c*l quand je vois le boulot abattu.

Et un grand merci pour la news bien sûr: elle est claire, précise, bien documentée...

[^]Re: Fast forward

Posté par Mickaël L () le 09/07/2007 à 09:43. (lien). Évalué à 4.
> Greg Kroah-Hartman s'est servi du logiciel développé par Linux Weekly News

On l'appelle Jonathan Corbet ;) ou "grumpy editor" parfois
Il y a plusieurs personnes à LWN

[^]Re: Fast forward

Posté par Matthieu Lemerre () le 09/07/2007 à 17:49. (lien). Évalué à 6.

Et après on se demande pourquoi Microsoft ne peux pas suivre le rythme !

Oui enfin il faut se dire que si les "bonnes" lignes avaient ete ecrites directement au lieu d'etre reecrites incrementalement on serait arrive au meme resultat avec bien moins de patchs...

La qualite d'un logiciel ne se mesure pas a son nombre de ligne de code (j'aurais tendance a penser le contraire: un bon logiciel en fait beaucoup en peu de lignes).

Note: non, je ne suis pas pro-microsoft (qui a d'ailleurs le meme genre de strategie je pense)
- [^]Re: Fast forward
  
  Posté par oops (page perso, ) le 10/07/2007 à 08:51. (lien). Évalué à 1.
  
  Oui enfin il faut se dire que si les "bonnes" lignes avaient ete ecrites directement au lieu d'etre reecrites incrementalement on serait arrive au meme resultat avec bien moins de patchs...
  
  Ben oui quoi, pourquoi ils ne font pas un noyau parfait dès le départ !!!
  Ils sont vraiment mauvais ces développeurs Linux.
  
  La qualite d'un logiciel ne se mesure pas a son nombre de ligne de code (j'aurais tendance a penser le contraire: un bon logiciel en fait beaucoup en peu de lignes).
  
  http://widefox.pbwiki.com/Source pour voir un comparatif : près de 2 fois moins de lignes de code pour Linux ( qui supporte pourtant bien plus d'architectures )
  - [^]Re: Fast forward
    
    Posté par Mathieu SCHROETER (page perso, ) le 10/07/2007 à 09:13. (lien). Évalué à 2.
    Honnêtement on sait pas d'où viennent ces chiffres.. l'indice 26 dit que c'est une estimation.. mais estimé par rapport à quoi? Ce comparatif manque de pertinence.
    - [^]Re: Fast forward
      
      Posté par oops (page perso, ) le 10/07/2007 à 09:27. (lien). Évalué à 1.
      
      l'indice 26 dit que c'est une estimation.. mais estimé par rapport à quoi? Ce comparatif manque de pertinence.
      
      Par rapport à la taille des binaires ?
      Par rapport à ce qui ont pu voir ceux qui ont accès aux sources ?
      Par rapport à ceux que disent dit Ballmer ?
      
      Je ne sais pas mais une recherche sur google donne entre 2,5 et 5 fois plus.
      
      Ce qui me parait normal vu qu'ils ont une gestion de la compatibilité ascendante.
      - [^]Re: Fast forward
        
        Posté par pasBill pasGates () le 11/07/2007 à 00:27. (lien). Évalué à 5.
        Cet article est une connerie sans nom :
        
        a) le Kernel de Vista sans drivers fait beaucoup, beaucoup, _beaucoup_ moins que 10 millions de lignes. L'OS entier en fait genre 50-60, croire que le kernel fait 20% de cela c'est un gros gag. Je viens de calculer le chiffre en faisant un compte des lignes de tous les fichiers dans le repertoire et c'est a des annees lumieres de 10 millions.
        
        b) On ne sait pas comment ils calculent ces chiffres (au hasard, la stack reseau n'est pas architecturalement parlant dans le kernel mais un driver dans Windows, il compte ca ? )
        
        c) Le gars qui a pondu cette page ne sait clairement pas de quoi il parle et s'amuse a scotcher des chiffres pris n'importe comment, genre sa mesure de nombre de bugs, il utilise un chiffre de 63'000 du temps de Win2k qui etait une rumeur et qui ne correspond absolument au nombre de defauts, mais au nombre de chose a changer (feature request, probleme dans la doc, ...).
        
        Tu peux oublier ces chiffres, ils ne valent rien du tout et sont totalement faux.
        
        [^]Re: Fast forward
        
        Posté par Gilles G. () le 11/07/2007 à 06:16. (lien). Évalué à 1.
        C'est vrai que tu bosses sur le noyau toi!!
        
        Merci pour l'info en tout cas.
        Si j'ai bien compris, le noyau Vista est de l'ordre de taille du noyau Linux donc...(en lignes de code) ?
        
        [^]Re: Fast forward
        
        Posté par Mathieu SCHROETER (page perso, ) le 11/07/2007 à 08:37. (lien). Évalué à 1.
        Le noyau des Windows NT donc Vista est un micro-noyau.. rien à voir avec Linux qui est monolithique-modulaire. En principe celui de Vista est plus petit (*que* le noyau donc!).
        
        [^]Re: Fast forward
        
        Posté par ndv (Jabber id, ) le 11/07/2007 à 09:58. (lien). Évalué à 2.
        J'avais pour ma part compris que le noyau Windows n'avait jamais été un vrai micro-noyau, car il reprenait aussi certains concepts des noyaux monolithiques.
        
        Wikipedia semble le confirmer :
        http://fr.wikipedia.org/wiki/Noyau_windows_NT
        
        Précisions sur les noyaux hibrides :
        http://fr.wikipedia.org/wiki/Noyau_%28informatique%29#Noyaux(...)
        
        [^]Re: Fast forward
        
        Posté par Xavier Teyssier (Jabber id, page perso, ) le 11/07/2007 à 13:09. (lien). Évalué à 2.
        A priori, selon pasBill pasGates , le coeur de NT n'est pas un micro-noyau (cf http://linuxfr.org/comments/31928.html#31928)
        
        [^]Re: Fast forward
        
        Posté par pasBill pasGates () le 11/07/2007 à 16:16. (lien). Évalué à 4.
        Il en a l'architecture(exemple habituel: la stack reseau est un driver que tu peux decider de charger/ne pas charger, elle est pas soudee dans le kernel), mais la plupart des drivers tournent en kernel mode.
        
        [^]Re: Fast forward
        
        Posté par pasBill pasGates () le 11/07/2007 à 16:19. (lien). Évalué à 1.
        Pas directement sur le noyau, mais le code est la donc je l'ai compte.
        
        Quand a la taille exacte, pas sur que j'ai le droit de donner le chiffre, mais de toute facon a mon avis le chiffre de cette page sur le noyau Linux est probablement faux aussi, sans parler du fait que MS et le noyau ont des demandes differentes niveau commentaires dans le code, donc c'est pas vraiment comparable de toute facon.
        
        [^]Re: Fast forward
        
        Posté par windu.2b (Jabber id, page perso, ) le 11/07/2007 à 19:18. (lien). Évalué à 5.
        
        sans parler du fait que MS et le noyau ont des demandes differentes niveau commentaires dans le code
        
        Si même toi, tu en viens à reconnaitre que MS ne commente pas son code, et que c'est pour ça qu'ils mettent autant de temps pour publier un patch, alors c'est que tout fout l'camp ma bonne dame! :-p
        
        [^]Re: Fast forward
        
        Posté par herodiade () le 12/07/2007 à 08:39. (lien). Évalué à 3.
        C'est pour ça qu'il faut compter les lignes avec un utilitaire comme sloccount : il ne compte que les lignes de code, et zappe les fichiers autres que le code (makefiles, doc, ...), et les lignes de commentaires.
        
        En bonus, il décompose le décompte en sous-totaux par langages (ANSI C, C++, asm, ...). voir http://www.dwheeler.com/sloccount/ (ok, pour l'utiliser sous Windows, il faut Cygwin, mais il existe des outils équivalents et natifs, voir par ex. sur http://www.qsm.com/CodeCounters.html ou http://www.programurl.com/code-counter-pro.htm ).
        
        [^]Re: Fast forward
        
        Posté par vladislav askiparek () le 12/07/2007 à 17:48. (lien). Évalué à 1.
        Et puis, comparons ce qui est comparable!
        La qualité par exemple...
        
        [^]Re: Fast forward
        
        Posté par pasBill pasGates () le 12/07/2007 à 18:51. (lien). Évalué à 1.
        En voila une bonne idee, mais qqe chose me dit que certains ici vont etre decu du resultat.
  - [^]Re: Fast forward
    
    Posté par Matthieu Lemerre () le 10/07/2007 à 23:08. (lien). Évalué à 1.
    
    Ben oui quoi, pourquoi ils ne font pas un noyau parfait dès le départ !!!
    Ils sont vraiment mauvais ces développeurs Linux.
    
    Je dis pas, mais de la a faire 19 versions d'un scheduler en 3 mois...
    Mais c'est bien le pb de POSIX (et des interfaces POSIX-like en general): comme c'est sense faire fonctionner pleins de taches differentes, qui ont plein de workloads completements differents, avec la meme interface, on se retrouve a faire un scheduler qui doit inferer le comportement de tout un tas d'application avant d'agir en consequence.
    
    Alors je comprends bien: avec tous les workloads "classiques" qui doivent exister, il doit en falloir du temps pour tous les faire marcher... Jusqu'a ce qu'on trouve un nouvel exemple qui marche pas. Et hop, une version de plus!
    
    En tout cas je lui souhaite bien du courage.

La même rengaine...

Posté par Janfi (page perso, ) le 09/07/2007 à 08:35. (lien). Évalué à 4.

Merci pour ce récapitulatif très clair qui met à la portée du plus grand nombre la compréhension des changements dans cette nouvelle version.

Concernant l'intégration de la couche wifi devicescape, est-ce que cela signifie que pour les réseaux en WPA par exemple il ne sera plus nécessaire d'utiliser wpa_supplicant, fichiers de conf à la main et consorts ? On pourra enfin se connecter en entrant "simplement" la passphrase ?

Merci...

[^]Re: La même rengaine...

Posté par ribwund () le 09/07/2007 à 09:03. (lien). Évalué à 4.
Ca ne change rien pour l'utilisateur, uniquement pour le developpeur (plus besoin de réinventer la roue pour chaque driver).

Et pour se connecter "simplement", il suffit d'utiliser NetworkManager :)
- [^]Re: La même rengaine...
  
  Posté par Larry Cow () le 09/07/2007 à 09:40. (lien). Évalué à 7.
  Si, ça pourrait changer un truc quand même pour l'utilisateur, indirectement.
  
  Si les drivers dupliquent moins de code, on peut s'attendre à une plus grande homogénéité entre eux, et donc un meilleur support par les outils graphiques. Finie, la déception de constater que sa distribution comporte un merveilleux outil de configuration du wifi, mais que sa carte réseau n'est pas supportée et doit être configurée à la main.
  - [^]Re: La même rengaine...
    
    Posté par Taku (page perso, ) le 09/07/2007 à 10:32. (lien). Évalué à 6.
    Tout à fait d'accord, tout amélioration apportée à tout ce qui concerne le support du matériel reste l'un des vecteurs les plus forts d'encouragement à la migration vers linux.
    
    Combien de "ca marche pas sous linux mon wifi" sur les forums de diverses distributions ?
    
    --
    Moi j'aime les fourmis !

[^]Re: La même rengaine...

Posté par Sébastien TeRMiToR (page perso, ) le 10/07/2007 à 07:25. (lien). Évalué à 2.
je confirme , sur gutsy avec une rc du 2.6.22 ma ralink 2500 pci marche enfin avec network-manager, et propose meme wpa , pour te dire le progres enorme de pouvoir passer en WPA.

Bien a vous
- [^]Re: La même rengaine...
  
  Posté par djibb (Jabber id, page perso, ) le 10/07/2007 à 11:47. (lien). Évalué à 2.
  c pas nouveau le WPA avec du rt2500... ca nécessitait de se farcir le module rt2500 (et pas rt2x00) mais à part ça...
  
  c'est le WPA2 que j'attends. il est peut etre inclus dedans ?

Fin de la branche CK

Posté par paul () le 09/07/2007 à 08:46. (lien). Évalué à 10.

Avant tout, bravo pour ce récapitulatif comme d'habitude d'excellente qualité sur le fond comme sur la forme.
Comme tu l'as relevé, la concurrence est rude pour l'inclusion dans la sacro-sainte branche vanilla. Et cette concurrence, dont chacun appréciera à sa façon la loyauté, aura provoqué indirectement le départ de Con Kolivas, auteur de la branche CK. Depuis des années, les patchs les plus innovant en matière d'ordonnancement, d'allocation, et de performance en général trouvent leurs chemin en premier lieu dans la branche de Con Kolivas. Ce dernier, après avoir mis au point un ordonnanceur particulièrement intéressant, a souhaité une inclusion dans la branche Vanilla. La sagesse prévalant, la discussion sur les atouts indéniables des concepts du Staircase Deadline a été longue [1]. Ingo Molnar, le développeur préposé depuis longtemps à l'ordonnancement dans la branche de linus, a développé son propre ordonnanceur, le CFS, principalement basé sur SD, et a reçu les faveurs de linus. Ensuite, CK s'est entendu dire que ce serait une duplication d'effort de maintenir 2 ordonnanceurs équivalents, donc que SD n'avait pas vraiment sa place dans le vanilla vu que CFS va y rentrer [2].
Con Kolivas, ayant trouvé que c'était quand même un peu gros, et pensant que la concurrence logicielle ne justifie pas le manque de considération pour les individus, a décidé de tirer sa révérence définitivement. Son patchset pour ce noyau 2.6.22 sera donc le dernier [3]. Merci pour tous ses apports logiciels et pour toutes ses idées, mais surtout, merci à lui pour son engagement et son temps passé sur linux.

[1] http://linuxfr.org/comments/825903.html#825903
[2] http://news.gmane.org/gmane.linux.kernel.ck
[3] http://members.optusnet.com.au/ckolivas/kernel/

--
paul

[^]Re: Fin de la branche CK

Posté par oliv () le 09/07/2007 à 18:37. (lien). Évalué à 10.
Je trouve que tu présentes ce problème sous un aspect partial très favorable à Con Kolivas. En tant que lecteur quotidien de la LKML depuis 7-8 ans, mon opinion est très différente. Elle est sans doute partiale elle aussi. CFS a eu les faveurs de la communauté pour plusieurs raisons:
1- Il est jugé techniquement supérieur
2- Ingo Molnar est capable de travailler en équipe et d'accepter les contributions d'autres personnes à "son bébé". Il suffit de regarder les changelogs de CFS pour voir que de nombreuses améliorations ne sont pas de lui. Dans un projet aussi communautaire que linux, c'est fondamental (cf. la situation de la couche IDE des noyaux 2.0, 2.2).
3- Ingo Molnar lance un projet et le maintient ou bien lui trouve un autre mainteneur (le dernier noyau realtime a été annoncé par Thomas Gleixner qui à l'origine était un petit contributeur, et maintenant est le principal contributeur de ce patch). Quelques temps après avoir créé SD, Kolivas a du s'arrêter de développer pour des raisons de santé. C'est ce qui a poussé Ingo Molnar à lancer CFS. Il n' y avait personne qui pouvait/voulait continuer le travail de Con Kolivas. C'est important d'avoir l'assurance que tel ou tel projet sera maintenu.
4- La lecture de la liste de diffusion du noyau montre que Con a commis quelques erreurs: des accusations paranoïaques et de tricherie contre CFS (e.g. l'histoire du renice de X). De son coté, Ingo Molnar a toujours rendu à César ce qui lui appartient. Il a clairement déclaré que certains concepts venaient de Kolivas, et n'a jamais dans ses changelogs, prétendu que son poulain était le meilleur.
5- Quand des défauts, bugs ou problèmes plus conceptuels ont été abordés pour les deux projets, Ingo Molnar a comme d'habitude corrigé les bugs (dans les heures qui suivaient). Cela fait de nombreuses version de CFS où il n' y a pas de bugs (il y a une constante: des gens rapportent des bugs, et réalisent ensuite qu'il se sont trompés où que le bug est en fait présent sous le noyau de base ou du à autre chose (e.g. le cas d' un bug de XTerm la semaine dernière)). Les problèmes soulevées par Bill Davidsen contre SD n'ont jamais reçu de réponse, ce qui a poussé Linus a faire un rappel à l'ordre.

Bref, Con a fait du bon boulot techniquement, et le patch "swap-prefetch" a toutes les chances d'être intégré au noyau, mais il n' a pas su gérer l'aspect humain de la contribution: accepter les critiques, accepter des devoir adapter son code au noyau, et non pas l'inverse.

Mais c'est mon opinion sur cette triste histoire, je le reconnais.
- [^]Re: Fin de la branche CK
  
  Posté par patrick_g (page perso, ) le 09/07/2007 à 19:22. (lien). Évalué à 4.
  Excellent résumé de la situation. C'est aussi ce que je pense après avoir suivi l'histoire sur la LKML.
- [^]Re: Fin de la branche CK
  
  Posté par Edouard Gomez (page perso, ) le 11/07/2007 à 09:38. (lien). Évalué à 9.
  > CFS a eu les faveurs de la communauté pour plusieurs raisons:
  > 1- Il est jugé techniquement supérieur
  
  Son design fait intervenir des structures plus complexes a manipuler que le Staircase Deadline (SD). Si bien qu'il ajoute des lignes de code a sched.c là ou SD en enleve et le rend plus simple a maintenir.
  
  > 2- Ingo Molnar est capable de travailler en équipe et d'accepter les contributions d'autres personnes à "son bébé". Il suffit de regarder les changelogs de CFS pour voir que de nombreuses améliorations ne sont pas de lui. Dans un projet aussi communautaire que linux, c'est fondamental (cf. la situation de la couche IDE des noyaux 2.0, 2.2).
  
  Ingo est un vieux routard du noyau, il a une aura dans la communauté LKML qui attire beaucoup plus qu'un pauvre gars, même pas informaticien qui tente de convaincre son monde depuis bientot 5 ans au travers de patchs toujours refusés upstream faute de consensus/perseverence.
  
  > 3- Ingo Molnar lance un projet et le maintient ou bien lui trouve un autre mainteneur (le dernier noyau realtime a été annoncé par Thomas Gleixner qui à l'origine était un petit contributeur, et maintenant est le principal contributeur de ce patch). Quelques temps après avoir créé SD, Kolivas a du s'arrêter de développer pour des raisons de santé. C'est ce qui a poussé Ingo Molnar à lancer CFS. Il n' y avait personne qui pouvait/voulait continuer le travail de Con Kolivas. C'est important d'avoir l'assurance que tel ou tel projet sera maintenu.
  
  Faux, CFS n'est pas du au retrait de Con Kolivas suite a sa maladie.
  
  1- Con est tombé malade suite au stress et travail imposé par la LKML sur son scheduler. En gros il propose un patch et au lieu d'y contribuer tout le monde l'a fusillé en lui disant que l'idée est bonne, mais l'implémentation n'est pas ce qu'ils attendaient.
  
  2 - Ingo a validé le concept mais a lui aussi refusé l'implementation de Con. Il disparait et reapparait avec son CFS.
  
  > 4- La lecture de la liste de diffusion du noyau montre que Con a commis quelques erreurs: des accusations paranoïaques et de tricherie contre CFS (e.g. l'histoire du renice de X).
  
  Le renice de X est une vérité vraie. Je 'tinvite a relire la LKML il y a quelques années ou Ingo et Linus defendaient le fait que renicer X c'etait pas la bonne approche dans la course a l'interactivité.
  
  Il est donc compréhensible que Con trouve que le renice automatique de X dans les premieres version de CFS soit de la pure triche pour pallier au manque d'interactivité de CFS dans sa jeunesse.
  
  > De son coté, Ingo Molnar a toujours rendu à César ce qui lui appartient. Il a clairement déclaré que certains concepts venaient de Kolivas, et n'a jamais dans ses changelogs, prétendu que son poulain était le meilleur.
  
  Oui et non, il est comprehensible que Con qui bosse depuis plusieurs années sur l'amelioration du scheduler ait les boules.
  
  Il s'est fait refuser le staircase scheduler, bien qu'il eut:
  - été plus simple que le scheduler mainline
  - intégré la notion d'interactivité de facon naturelle et deterministe.
  
  Il s'est fait refuser RSDL (Rotating Staircase Deadline Scheduler) et SD:
  - car l'approche etait un peu hors norme
  - car personne ne l'a vraiment concretement aidé à l'ameliorer en respectant le design de base (y a eu des patchs envoyes pour integrer des heuristiques de bonus d'interactivité par celui qui tune ce meme parametre dans le noyau mainline depuis quelque temps). Mais le fameux 'envoies ton patch au lieu de critiquer gratuitement' a pas eu lieu. Les critiques etaient là, les patchs non.
  
  On peu donc comprendre que l'arrivée de CFS soit mal percue. Ingo n'a pas patché SD, il s'est mis a coder dans son coin en repompant l'idee de base, fait un truc a sa sauce, et attiré les developpeurs interesses car il est plus affluant dans la communauté LKML.
  
  > 5- Quand des défauts, bugs ou problèmes plus conceptuels ont été abordés pour les deux projets, Ingo Molnar a comme d'habitude corrigé les bugs (dans les heures qui suivaient). Cela fait de nombreuses version de CFS où il n' y a pas de bugs (il y a une constante: des gens rapportent des bugs, et réalisent ensuite qu'il se sont trompés où que le bug est en fait présent sous le noyau de base ou du à autre chose (e.g. le cas d' un bug de XTerm la semaine dernière)). Les problèmes soulevées par Bill Davidsen contre SD n'ont jamais reçu de réponse, ce qui a poussé Linus a faire un rappel à l'ordre.
  
  48 versions de SD, c'est peut etre pas assez ?
  
  En fait, tu disais que le post original de la thread etait biaisé en faveur de Con, et bien j'ose dire que le tien est clairement biaisé en faveur d'Ingo.
  
  L'erreur c'est que tu as uniquement suivi la LKML pour te faire une idee, et SD a été développé sur la mailing list de Con Kolivas. Cela explique certainement ta partialité.
  
  Mais ayant vu les choses sur les deux MLs, je dirais que Ingo a fait un petit coup de pute a Con:
  - il ne l'aide pas
  - il deprecie le design
  - il vient avec un concurrent
  - il attire a lui tous ceux qui seraient en mesure d'aider Con
  - il renie certaines choses qu'il a rejeté des années durant pour son scheduler O(1) mainline (modularité, pas de bonus d'interactivité ...).
  
  Donc oui, Con a eu les boules, c'est normal.
  
  Ingo a mergé son CFS, tant mieux pour Linux qui profitera d'un scheduler techniquement supérieur au mainline 2.5.x->2.6.21.
  
  PS: malgré mon plaidoyer pour Con, je trouve qu'Ingo fait du super boulot. C'est juste la facon de faire qui a été "border line" et que j'ai trouvé un peu irrespectueuse humainement.
  - [^]Re: Fin de la branche CK
    
    Posté par patrick_g (page perso, ) le 11/07/2007 à 09:51. (lien). Évalué à 3.
    Dans le fichier de documentation de CFS on trouve ces phrases écrites par Ingo :
    
    "I'd like to give credit to Con Kolivas for the general approach here: he has proven via RSDL/SD that 'fair scheduling' is possible and that it results in better desktop scheduling. Kudos Con!"
    
    Donc Ingo reconnait parfaitement avoir utilisé l'idée originale de Con et il attribue correctement le crédit de cette idée (et ajoute ses remerciements).
    
    Ensuite il a l'air de dire (ce qui est normal) que sa solution est techniquement supérieure :
    
    "CFS's design is quite radical: it does not use runqueues, it uses a time-ordered rbtree to build a 'timeline' of future task execution, and thus has no 'array switch' artifacts (by which both the vanilla scheduler and RSDL/SD are affected)."
    - [^]Re: Fin de la branche CK
      
      Posté par imalip (page perso, ) le 11/07/2007 à 14:36. (lien). Évalué à 6.
      
      Donc Ingo reconnait parfaitement avoir utilisé l'idée originale de Con et il attribue correctement le crédit de cette idée (et ajoute ses remerciements).
      
      Chouette. Le mec a bossé sur un systeme pendant des années, s'est fait allumer, et des qu'il est indisponible, les memes qui l'ont allumé reprennent les idées qu'il a développées. Mais il a droit a une ligne de remerciement dans "le nouveau scheduler CFS d'Ingo Molnar", alors il peut fermer sa gueule.
      A ce tarif la, je veux bien comprendre qu'il l'ait un peu mauvaise et laisse tomber le projet, je suis déja passé par la...
      
      --
      "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
  - [^]Re: Fin de la branche CK
    
    Posté par David () le 11/07/2007 à 13:30. (lien). Évalué à 10.
    Pour preciser, Kolivas exerce le metier de medecin anesthesiste, et developpe sur son temps libre. De son cote, Ingo Molvar est developpeur kernel chez Red Hat.
    
    Interviews de 2002 :
    Kolivas : http://kerneltrap.org/node/465
    Molvar : http://kerneltrap.org/node/517
    
    Un resume tres complet des echanges entre Kolivas et Molvar sur LKML :
    http://kerneltrap.org/node/8059/L
    
    Pour ma part, je vois 2 lamentables erreurs de gestion humaine :
    
    - Molvar affirme avoir creer CFS en 62 heures, plus 6 heures de test. Il s'est fonde sur les idees de Kolivas qui travaille sur le sujet depuis plusieurs annees. Mais Molvar n'a pas trouve necessaire d'en discuter 1 minute avec Kolivas avant de poster son patch CFS sur LKML.
    
    - Les mainteneurs (Torvalds, Molvar, Piggin et d'autres) ont souvent regarde de haut les patchs CK. Puis Torvalds en a remis une couche en soutenant Molvar sur LKML, comme quoi rivalite et tension participe a la qualite du kernel...
    
    Ma conviction (tout a fait personnelle), c'est que Molvar ne devait pas trop apprecie que depuis 2002-3 un gus australien developpant sur son temps libre viennent marcher sur ses plate-bandes, en disant que le scheduler o(1) n'etait pas si bon que ca.
    (autre conviction : Torvalds est un super ingenieur, mais un pietre manager).
    
    Sequence souvenir (26 juillet 2003) :
    http://www.ussg.iu.edu/hypermail/linux/kernel/0307.3/0554.ht(...)
    
    "As the last point, I do want to invite Ingo and Con to work together to fix things up definitively. I feel Con scheduler patches give better interactive results (at least for me) but still feels a little bit slow when the system is under heavy load and I try to launch new processes, like a new xterm, for example. On the other side, Ingo patch makes the system feel much more responsive under heavy loads when launching new processes, like opening a new konsole tab, but still suffers from jerkyness on interactive tasks, like the X server."
    
    --
    -- Front de Libération des Sources --
    Pour stopper les trolls, citons les sources !
    - [^]Re: Fin de la branche CK
      
      Posté par Gabriel Linder () le 11/07/2007 à 13:51. (lien). Évalué à 2.
      Tu as extrêmement bien résumé la situation (de ce que j'en sais), à un détail près : le gus s'appelle Ingo Molnar, pas Molvar :)
      - [^]Re: Fin de la branche CK
        
        Posté par David () le 11/07/2007 à 18:46. (lien). Évalué à 3.
        Ca et les fautes de conjugaison... j'ai honte!! :-[
        
        --
        -- Front de Libération des Sources --
        Pour stopper les trolls, citons les sources !
    - [^]Re: Fin de la branche CK
      
      Posté par paul () le 12/07/2007 à 13:46. (lien). Évalué à 10.
      
      Ma conviction (tout a fait personnelle), c'est que Molvar ne devait pas trop apprecie que depuis 2002-3 un gus australien developpant sur son temps libre viennent marcher sur ses plate-bandes, en disant que le scheduler o(1) n'etait pas si bon que ca.
      
      C'est tout à fait l'impression que cette histoire me laisse également. D'un coté un développeur payé par red-hat dont le boulot à plein temps est de faire de l'ordonnancement dans le kernel. De l'autre un médecin avec sa petite famille qui prend de son temps libre pour trafiquer le noyau. Ce dernier n'est pas vraiment de la bande à linus, il se permet de dire que certaines portions du kernel pourraient être améliorées, et puis il le prouve en le faisant.
      
      En résumé, voici une reconstitution fortement exagérée de ce qui a pu se passer :
      
      Kolivas : bon, o(1) c'est sympa mais parfois j'ai du lag dans les applications, je pense qu'on pourrait peut-être remplacer la contrainte de ...
      Molnar : bullshit on peut pas faire mieux
      
      ----- un peu plus tard ----
      
      Kolivas : c'est bon j'ai un nouvel ordonnanceur qui s'appelle RSDL, testez-le pour voir
      
      ---- linus et molnar en privé ----
      Molnar : eh linus, y'a le toubib' qui r'commence à faire mon taff', comment tu veux que je justifie ma paye moi après ?
      linus : bon sang mais c'est que ça marche sacrément bien son machin en plus, ça me dirait bien de l'utiliser mais j'ai pas envie de passer pour une bille en admettant sa supériorité
      molnar : et moi donc !
      linus : tu sais quoi, de toute façon ce mec m'énerve, c'est moi le roi ici, i am the king, et y'a que moi qui ai le droit de dire quand un truc c'est de la merde ! Tiens t'as qu'à lire un peu son code, moi je m'arrange pendant ce temps, je vais bien lui trouver un truc, au pire je le traiterai de nazi.
      
      --- de retour sur la LKML ---
      linus : Kolivas, c'est bien ton truc, mais faudrait faire ça ça et ça en plus, pour la semaine prochaine
      (...)
      kolivas : voila linus, c'est fait
      linus : ah, euh, ok, bon alors tu feras ceci, cela, et aussi ça ça ça et ça et puis aussi ça et tu referas ça, le tout pour demain !
      (...)
      kolivas : voila
      linus : bon sang j'en ai marre, maintenant tu recommences tout à zéro et je veux qu'en lisant les premières lettres de chaque ligne de ton code ça fasse un pamphlet à ma gloire, tu dors pas et tu me fais ça pour demain matin et j'envisagerai de remplacer o(1) par SD
      kolivas : arg, glaps -> hosto
      
      --- sur la LKML ---
      molnar : eh les mecs j'ai un nouvel ordonnanceur, j'ai fait ça vite fait, je pense que d'ici une soixantaine de hacks et quelques renice ça fonctionnera bien
      linus : mais c'est suuuupaaaaiiiiiiiiiirre, quelle heureuse surprise, allez on l'adopte !
      kolivas : euh, mais le miens il fait mieux et depuis quelques mois, il est moins gros et moins dur à ...
      linus : ouais, mais toi t'es un qu'un sale faiblard, regarde t'es allé à l'hosto, t'es même pas capable de maintenir du code et puis t'façon y'a déjà CFS, t'as pas l'impression de venir faire double-emploi là ? Et puis le logiciel, c'est comme mon sexe, c'est meilleur quand c'est gros et dur.
      
      --The End--
      
      --
      paul
      - [^]Re: Fin de la branche CK
        
        Posté par Gabriel Linder () le 12/07/2007 à 14:20. (lien). Évalué à 2.
        De plus Linus contredit De Raadt sur les bugs des Core 2 Duo [1] en disant que " le problème des TLB n'est rien du tout " sauf que quand Theo disait " bugs critiques et dangereux " il ne pensait pas du tout aux TLB mais en visait d'autres... Bref il lit et commente ce qu'il veut bien lire et commenter, sa parole étant reprise comme la seule valable.
        
        [1] : http://article.gmane.org/gmane.os.openbsd.misc/126235
        et l'article dont ils parlent : http://blogs.zdnet.com/Ou/?p=559
        
        [^]Re: Fin de la branche CK
        
        Posté par EdB (page perso, ) le 12/07/2007 à 16:47. (lien). Évalué à 3.
        M'enfin la faut pas déconner, ce n'est pas de la faute de Linus quand il dit : "le problème des TLB n'est rien du tout" il ne parle que de la TLB.
        C'est les autres qui déforment et disent "regarde Linus dit que Theo raconte que des conneries".
        C'est aussi aux lecteurs et à toi d'être critiques.
        
        [^]Re: Fin de la branche CK
        
        Posté par Gabriel Linder () le 13/07/2007 à 07:06. (lien). Évalué à 2.
        L'article est titré "Linus contradicts OpenBSD founder on Intel TLB issue" et fait comme si Theo avait fait une montagne des TLB, c'est en ce sens qu'allait mon commentaire. Que Linus dise que le problème des TLB n'est rien est parfaitement correct, et je n'irais certes pas le lui reprocher.
        
        [+] [^]Re: Fin de la branche CK
        
        Posté par H_francis () le 13/07/2007 à 21:05. (lien). Évalué à -1.
        En fait c'est dommage parce que le concept philosophique de l'ordonnanceur c'est quand même d'être équitable avec les différents processus.
        
        Équitable dans le sens, équitable quoi, juste et honnête, Fair Scheduler, bien, qui respecte tout le monde quoi, comme linux et le travail communautaire, etc, bref, tous ces beaux concepts philosophiques qui sont quand même importants, comme le sheduler du noyau qui est important aussi, non?
        
        Bon dommage alors

Regressions et mac80211

Posté par herodiade () le 09/07/2007 à 09:26. (lien). Évalué à 10.

Maintenant que la liste des régression connues est maintenue sur un site web, ce serait bien d'inclure le lien dans les dépêches relatives à la sortie de nouvelles versions du noyau : http://kernelnewbies.org/known_regressions

Quelques précisions et compléments d'informations, en vrac :
* Puisqu'on parle de la liste des régressions. Adrian Bunk maintenait une telle liste durant les derniers mois, qu'il postait chaque semaine sur LKML. Fâché de l'insuccès de son travail (il considère que le 2.6.21 n'aurait pas du sortir en l'état), Bunk a décidé d'abandonner cette tache ingrate, au grand dam des autres développeurs (y compris de Linus) (cf. http://kerneltrap.org/node/8110 ). À cette occasion Google a rappelé qu'ils cherchent à embaucher un « bug master » pour le noyau Linux. Finalement Michal Piotrowski a pris les choses en main et maintient une liste des régression dans un wiki (à l'adresse citée plus haut).

* La nouvelle couche Wi-Fi (<- ça s'écrit comme ceci en fait) s'appelle mac80211 (ou encore d80211). Outres les fonctionnalités citées dans la dépêche, elle mutualise une implémentation MAC logicielle commune pour les divers pilotes, souvent nécessaire avec les chipsets modernes et sots, dits « softmac ». Son intégration dans le noyau standard a parait-il permis de la stabiliser, et simplifiera grandement l'intégration des pilotes récents (nombreux sont ceux qui l'utilisait déjà auparavant, bien qu'elle n'était pas incluse dans le noyau), comme iwlwifi (Intel 4965AGN), les pilotes ralink rt2x00, le nouveau pilote pour le chipset Marvel Libertas, le Broadcom bcm43xx, et bien d'autres. L'ancienne couche Wi-Fi (qui s'appelle ieee80211) est conservée dans le noyau (de nombreux « vieux » pilotes l'utilisent). La perspective d'une telle cohabitation - et du travail de maintenance qui s'en trouve doublé - fut la cause de nombreux débats sur les listes de diffusion. Remarquez aussi que l'API de configuration WEXT du ieee80211 est rendue obsolète par le nouveau mécanisme nommé cfg80211, basé sur netlink (API nl80211). Une couche de compatibilité est toutefois maintenue (avec l'aide, si je me souviens bien, d'une bibliothèque en espace utilisateur).

* La nouvelle couche FireWire (<- ça s'écrit ainsi) est certes plus dense (moins de lignes de codes) mais n'est pas tout à fait complète encore. Par exemple l'eth1394 (émulation ethernet sur FireWire) n'est pas encore porté, si vous utilisez cette fonctionnalité, attendez encore un peu.

[^]Re: Regressions et mac80211

Posté par patrick_g (page perso, ) le 09/07/2007 à 11:44. (lien). Évalué à 3.
Deux chose :
1) Merci pour le lien vers la liste des régressions. Effectivement c'est une bonne idée d'inclure ce lien lors d'une news kernel et je vais essayer de m'en souvenir pour celle du 2.6.23 (entre parenthèse la liste des régressions du 2.6.22 me semble minuscule par rapport à l'ampleur des changements).
2) Pour ce qui est de la présence de l'ancienne couche Wi-Fi : Elle n'a évidemment pas vocation à faire de vieux os dans le noyau et elle sera éliminée sans pitié dès que les derniers pilotes seront portés sur la nouvelle pile.
- [^]Re: Regressions et mac80211
  
  Posté par herodiade () le 09/07/2007 à 13:35. (lien). Évalué à 9.
  > entre parenthèse la liste des régressions du 2.6.22 me semble minuscule par rapport à l'ampleur des changements
  
  Remarque qu'il ne s'agit que des régressions connues : le noyau est toujours mieux testé juste après la sortie d'une nouvelle version (malheureusement !). Et il ne s'agit (presque) que de régressions, les bugs touchant des nouvelles fonctionnalités ou architectures ne sont pas des régressions. Pendant la phase de développement cette liste a été très longue, par moments. Elle a effectivement été sérieusement réduite (preuve, peut-être, de son efficacité : les problèmes n'ont pas été négligés).
  
  Je suis moins optimiste en ce qui concerne l'ancienne couche Wi-Fi : je n'ai pas l'impression que qui que ce soit travaille à l'adaptation des pilotes prism2.5 ou encore ipw2200, par exemple. Peut-être parce que mac80211 n'est (ou du moins n'était, récemment) pas encore tout à fait adapté aux chipsets fullmac (me semble-t-il avoir lu, je ne suis pas 100% sur que ce soit toujours vrai), et qu'il suffira d'attendre quelques mois de maturation. Peut-être aussi parce qu'il est difficile de restructurer complètement un logiciel éprouvé par le temps sans causer de grosses régressions.
  
  Mais il ne faut pas oublier qu'un certain nombre d'entre eux furent développées en interne par des sociétés commercialisant le chipset mais ne donnant pas les specs, ou sous NDA seulement, et qu'Intel, par exemple, n'a aucune envie de consacrer des ressources pour re-développer un produits qu'ils ne vendent plus, alors qu'il est tellement plus simple d'encourager les utilisateurs à changer de matériel. Quand on disait que « donner les specs, sans NDA, c'est beaucoup mieux que donner un driver GPL » ...
  - [^]Re: Regressions et mac80211
    
    Posté par patrick_g (page perso, ) le 09/07/2007 à 14:16. (lien). Évalué à 8.
    >>> Quand on disait que « donner les specs, sans NDA, c'est beaucoup mieux que donner un driver GPL » ...
    
    C'est clair et Theo à 100 fois raison de se battre là-dessus.
- [^]Re: Regressions et mac80211
  
  Posté par reno () le 09/07/2007 à 17:40. (lien). Évalué à 1.
  >>entre parenthèse la liste des régressions du 2.6.22 me semble minuscule par rapport à l'ampleur des changements<<
  
  <mode optimiste>
  Peut-être est-ce parce que les développeurs du noyau ont du sortir leur 'brown paper bag' (expression venant du sac utilisé pour 'cacher' les bières aux US il me semble, le pays étant "légèrement" puritain) pour la 2.6.21 et ont soigner la 2.6.22?
  </mode optimiste>
  - [^]Re: Regressions et mac80211
    
    Posté par gvallee () le 10/07/2007 à 03:43. (lien). Évalué à 9.
    En principe je ne reagis pas sur ce genre de remarques sur les US mais ce soir, je me jete a l'eau...
    
    Dans les "brown bags" sont bien les sacs en papier de couleur brune, utilises pour mettre les bouteilles d'alcool certes mais egalement utilises par exemple par les petites epicieries.
    
    Ensuite la vraie situation concernant l'alcool aux US est la suivante :
    - Dans la plupart des counties (comtes en bon francais) et des etats, il est interdit de boire de l'alcool sur le voie publique ; comme dans la majorite des communes francaises. La principale difference est qu'aux US, la loi est reellement appliquee. :-)
    - Dans la plupart des etats/counties, il est interdit d'avoir une bouteille d'alcool ouverte et apparente sur le voie publique. Tu fais ce que tu veux dans un lieu prive (toujours un peu comme la France).
    - Il existe des counties sec (dry counties), i.e., des counties ou la vente et l'achat d'alcool est interdit. Pour anecdote le distillerie Jack Daniels est dans un county sec.
    - Dans certains etats les supermarches ne peuvent pas vendre d'alcool, exception pour la biere. Pour trouver du vin ou des liqueurs il faut aller dans des "liquor shops".
    - Il est interdit d'avoir une bouteille d'alcool ouverte dans les parcs naturels regionaux et federaux.
    - Il est souvent interdit d'acheter de l'alcool le dimanche matin avant midi (au moins de ce que je sais dans le sud, dans la "bible belt").
    
    Bref, comme souvent, generaliser comme tu le fais sur les US n'a pas de sens quand tu connais un peu le pays. Il y a des differences enormes entre les etats et meme entre counties. Mais je suis egalement concient que beaucoup de gens ici ont simplement une animosite naturelle contre les US (je ne dis pas que c'est ton cas, je te connais pas personnellement).
    
    Au passage en Californie par exemple, je pense que l'on peut dire que les gens sont globalement moins puritains qu'en France.
    
    Mes 2 cents inutiles et hors sujet (vous pouvez donc moissonner).
    - [^]Re: Regressions et mac80211
      
      Posté par reno () le 10/07/2007 à 09:40. (lien). Évalué à 7.
      Dans ton texte, il y a "Dans la plupart des etats/counties, il est interdit d'avoir une bouteille d'alcool ouverte et apparente sur le voie publique" donc tu confirmes bien ma phrase sur la bouteille d'alcool que l'on doit cacher.
      
      Réglementation qui vient de la religion (wikipedia: puritain: conception de la foi chrétienne) et il me semble que même en Californie les gens sont toujours plus religieux qu'en France (même s'ils le sont moins bien que dans le reste des USA), sinon je suis plutôt d'accord avec toi sur le reste.
      - [^]Re: Regressions et mac80211
        
        Posté par gvallee () le 10/07/2007 à 14:30. (lien). Évalué à 4.
        Ce qui m'a fait tiquer dans ton message c'est que tu ne precises pas que les brown bags sont utilises "sur la voie publique" et que tu as ensuite conclu que les US sont puritains. Ne penses-tu pas que c'est une raccourci un peu facile et extreme? Tout comme dans beaucoup de villes francaises, il est interdit de boire en lieu publique. Dis-tu pour autant que la France est puritaine? Est-ce un probleme de mettre une bouteille dans un sac que tu l'achetes? je ne pense pas... Bois tu en lieu publique? si oui tres certainement que tu ne respectes pas la loi de ta commune... Bref si ca peut faire plaisir a des gens que je mette mes bouteilles d'alcool dans un sac quand je les achete, ok je fais l'effort, ca fait des heureux a peu de frais et de toute facon je fais toujours ca quelque soit le pays ou je ne trouve.
        
        De plus ca n'est pas parce que une minorite bruyante mais puissante (les puritains) fait passer des lois que tu dois te permettre de juger un pays en entier. D'autant qu'a ma connaissance, la loi sur l'alcool et les brown bags n'est pas directement lieu a un mouvement religieux, c'est a ma connaissance une loi "pour le respect de l'ordre" qui a une signification differernte ici (la notion de liberte est differente ici par rapport a la notion de liberte communement acceptee en France). Tu affirmes que c'est le cas, je suis interesse par tous pointeurs sur le sujet. L'interdiction de vendre de l'alcool le dimanche matin est par contre pour des raisons purement religieuses.
        
        Ensuite a ma connaissane, non les gens en Californie ne sont pas plus religieux (mais peut-etre que l'on ne donne pas la meme definition au terme) qu'en France. De maniere generale de toute facon, la plupart des gens aux US se foutent de ta religion et de tes habitudes. Car contre oui comme je l'ai dis plus haut une groupe puritain existe aux US, est puissant et fait du bruit... de la a "condamner" les US dans son entier, il ne faut pas pousser.
        
        <mode provocation>
        Et puis de toute facon, en voyageant tu te rends compte que les francais sont faineants bruleurs de voitures hein... je suppose que de la meme maniere les americains sont puritains.
        </mode provocation>
        
        Pour finir tu penses ce que tu veux, tu dis ce que tu veux. Personnellement j'ai la chance de connaitre un peu les US, je precise quelques points que tu mets en valeur et qui sont "deplaces". J'avais tendance a penser la meme chose que toi avant de decouvrir les US et en passant du temps sur place je me suis rendu compte que la majorite des prejuges que j'avais n'avaient aucune realite de masse (bref que c'etaient des generalisations deplacees).
        Maintenant j'arrete ici cette "conversation" qui n'a strictement rien a faire sur ce site et qui de toute facon ne va rien changer du tout.
        
        [^]Re: Regressions et mac80211
        
        Posté par Thomas Douillard () le 10/07/2007 à 18:55. (lien). Évalué à 3.
        Par curiosité, tu es d'où ? Certaines fautes de genre dans tes phrases me font dire que tu n'es pas Français ;) Le reste de ton message étant par ailleur rédigé dans un Français plutôt pas mal du tout.
        
        [^]Re: Regressions et mac80211
        
        Posté par gvallee () le 11/07/2007 à 17:21. (lien). Évalué à 3.
        Je suis un Francais vivant aux US depuis quelques annees. Les fautes sont dues au manque de sommeil (principalement parce que je travaille pas mal sur des logiciels libres ces derniers temps :-) et a l'utilisation de plusieurs langues sur une courte periode de temps. Ce qui bien sur n'excuse pas les dites fautes ; vraiment desole que mon texte en contienne autant.
        
        [^]Re: Regressions et mac80211
        
        Posté par reno () le 11/07/2007 à 05:40. (lien). Évalué à 3.
        >>Ce qui m'a fait tiquer dans ton message c'est que tu ne precises pas que les brown bags sont utilises "sur la voie publique" <<
        Je n'allais pas faire une tartine pour une plaisanterie a 2 cents.
        
        >>tu as ensuite conclu que les US sont puritains.<<
        C'est une bonne première approximation, il me semble pour expliquer cette réglementation, il ne faut pas chercher plus loin.
        
        >>non les gens en Californie ne sont pas plus religieux qu'en France.<<
        D'après une assistante d'anglais Américaine que j'ai eu, >80% des Américains vont au moins une fois par mois à l'église (en fait c'était encore plus élevé que ça), chiffre très très supérieur a la fréquentation des églises Française (qui ont tendance a être peu fréquentée).
        
        C'était une moyenne pour tout les USA, j'ignore quel est le chiffre pour la Californie, mais s'il correspondait a la moyenne Française, il faudrait que dans les autres états, ils aillent a 150% l'église.
        Après peut-être qu'elle a dit une bêtise, mais comme elle était Américaine, je lui ai fait confiance pour ce point.
        
        [+] [^]Re: Regressions et mac80211
        
        Posté par gvallee () le 11/07/2007 à 17:31. (lien). Évalué à -1.
        Les 80% ne correspondent pas a mon experience (et comme je le vis, j'ai tendance a le croire). De plus dans ma famille (francaise) et mon cercle d'amis proches, une bonne proportion des gens sont catholiques ou musulmans mais ne vont pas forcement a l'eglise ou a la mosquee au moins une fois par mois. Je n'estime pas pour autant qu'ils sont moins religieux... le religion a une place tout aussi importante dans leur vie pour que la majorite des americains. Bref, on n'a donc clairement pas la meme definition de "religieux".
        
        Mais bon c'est une discussion sterile...

Support de Blackfin

Posté par Boa Treize (page perso, ) le 09/07/2007 à 09:53. (lien). Évalué à 3.

Intéressant ça. C'est l'architecture des Livebox Sagem, je crois. À quand un OS 100% libre dans une Livebox ? :-)

[^]Re: Support de Blackfin

Posté par baud123 (Jabber id, page perso, ) le 09/07/2007 à 10:27. (lien). Évalué à 2.
c'est déjà le cas il me semble, hormis sans doute un pilote wifi broadcom proprio comme d'hab' (mais je dois être mauvaise langue).
- [^]Re: Support de Blackfin
  
  Posté par Boa Treize (page perso, ) le 09/07/2007 à 11:09. (lien). Évalué à 4.
  Par OS 100 % libre, je voulais aussi dire "avec accès shell sans contrainte". Et des outils systèmes pas trop pourris niveau interface ligne de commande. Parce que le telnet Livebox, c'est quand même une belle horreur.
  - [^]Re: Support de Blackfin
    
    Posté par jon207 (Jabber id, page perso, ) le 09/07/2007 à 16:36. (lien). Évalué à 1.
    je confirme. je suis même pas sur de pouvoir changer le mot de passe par défaut (en tout cas passwd ne fonctionne pas). et puis ils auraient pu trouver mieux comme identifiants que "root 1234". et en plus elle est moche la livebox.
    
    --
    "La liberté ne peut être que toute la liberté ; un morceau de liberté n’est pas la liberté." -- Max Stirner

Merci

Posté par chaica () le 09/07/2007 à 10:13. (lien). Évalué à 2.

Merci pour cette news claire et complète.

Qu'est-ce que « eventfd » ?

Posté par Laurent A. () le 09/07/2007 à 19:34. (lien). Évalué à 2.

Je ne comprends pas bien ce qu'est censé faire cette nouvelle interface. A-t'elle un rapport avec Inotify ? J'ai l'impression que non mais je vois aussi que ça parle d'évènements d'I/O sur des fichiers...
Si ces deux interfaces n'ont aucun rapport entre elles, est-ce que quelqu'un sait si des améliorations sont prévus pour Inotify ? Je pense notamment à ne plus avoir une limite sur le nombre de fichiers « monitorables », ou encore sur la possibilité de lancer Inotify sur tous les sous-dossiers d'une arborescence sans avoir à la parcourir manuellement.

[^]Re: Qu'est-ce que « eventfd » ?

Posté par patrick_g (page perso, ) le 10/07/2007 à 05:43. (lien). Évalué à 4.
Cet article explique bien le mécanisme d'eventfd => http://lwn.net/Articles/225714/

CFS dans 2.6.23 !

Posté par Sebastien Binet () le 09/07/2007 à 23:59. (lien). Évalué à 7.

Enfin le nouvel ordonnanceur CFS d'Ingo Molnar (évoqué lors de la dépêche sur le noyau 2.6.21) en est à sa dix-neuvième version et le temps de l'inclusion dans la branche principale approche à grands pas !

Ca y est, il est dans la branche principale:
http://lwn.net/Articles/241085/rss

[^]Re: CFS dans 2.6.23 !

Posté par Gabriel Linder () le 11/07/2007 à 10:55. (lien). Évalué à 2.
Tant mieux, parce que le système est vraiment beaucoup plus réactif avec ce scheduler (même par rapport à SD, que j'utilisais jusqu'à présent mais maintenant que -ck n'est plus maintenu il faut bien se mettre à jour) !

$ cat /proc/version
Linux version 2.6.22.1-cfs-v19-dargor (root@oblivion) (gcc version 4.1.2) #1 SMP PREEMPT Wed Jul 11 09:52:58 CEST 2007
- [^]Re: CFS dans 2.6.23 !
  
  Posté par gpe () le 11/07/2007 à 15:33. (lien). Évalué à 0.
  
  Tant mieux, parce que le système est vraiment beaucoup plus réactif avec ce scheduler (même par rapport à SD, que j'utilisais jusqu'à présent mais maintenant que -ck n'est plus maintenu il faut bien se mettre à jour) !
  
  Déjà que je trouve un Linux normal (2.6.18) bien plus réactif et fluide qu'un Windows XP alors avec CFS...

[^]Re: CFS dans 2.6.23 !

Posté par David () le 11/07/2007 à 11:48. (lien). Évalué à 4.
Est-ce que ce nouveau scheduler a un impact sur la consommation CPU, ou est-ce que reactivite et conso sont totalement decorelees ?

--
-- Front de Libération des Sources --
Pour stopper les trolls, citons les sources !
- [^]Re: CFS dans 2.6.23 !
  
  Posté par Gabriel Linder () le 11/07/2007 à 13:58. (lien). Évalué à 1.
  De ce que j'en ressens le système est plus "fluide" et les CPUs moins sollicités, la charge étant mieux répartie entre les coeurs (ceci ne concerne que mon P4 HT, je n'ai pas encore testé sur un vrai dual core, je prévois de recompiler le kernel de mon laptop ce soir). Avec SD il était habituel de voir un core à 90% et l'autre à 0% lors des compilations de kernels, avec CFS les deux cores tournent à un rythme identique. Sous forte charge les applications sont plus rapides à se lancer qu'avec SD (genre xterm et top pour voir ce qui se passe).
- [^]Re: CFS dans 2.6.23 !
  
  Posté par reno () le 11/07/2007 à 18:35. (lien). Évalué à 3.
  Tu peux préciser, parles-tu de la consommation électriques des CPU ou de la charge CPU?
  - [^]Re: CFS dans 2.6.23 !
    
    Posté par David () le 11/07/2007 à 18:59. (lien). Évalué à 3.
    Je parle de consommation electrique : par exemple, il a ete recemment annonce que la modification des timers pour les rendre tickless prolongeait l'autonomie des PC portables.
    
    En est-il de meme pour l'ordonnanceur CFS, ou est-ce sans incidence ?
    
    --
    -- Front de Libération des Sources --
    Pour stopper les trolls, citons les sources !
    - [^]Re: CFS dans 2.6.23 !
      
      Posté par reno () le 12/07/2007 à 05:00. (lien). Évalué à 4.
      A priori, je dirais sans incidence: la modification de l'ordre d'activation des taches ne change pas la charge globale donc pas non plus la consommation électrique.
      
      Bon, ce n'est pas 100% vrai: par exemple une future modification (sur la gestion des timers il me semble) consiste a regrouper le lancement des taches: plutot qu'avoir:
      tache A: t: 0, 1, 2, 3
      tache B: t 0.5 1.5 2.5
      il vaut mieux avoir tache A et B: 0 1 2 3 d'un point de vue consommation électrique, car le CPU reste libre plus longtemps entre les deux, donc peut être mis dans un mode de consommation électrique plus faible plus longtemps.
      - [^]Re: CFS dans 2.6.23 !
        
        Posté par herodiade () le 12/07/2007 à 08:36. (lien). Évalué à 6.
        C'est déjà le cas. Il y a dans le noyau, depuis la version 2.6.19 (ou 2.6.20 ?) les fonctions round_jiffies() et round_jiffies_relative() qui arrondissent à la seconde pleine les valeurs de jiffies passées en argument.
        
        L'idée est que dans de très nombreux cas, on a besoin de programmer une tâche dans le futur, ou à intervalle régulier, mais on n'a pas nécessairement besoin que la date d'exécution de cette tache soit vraiment précise à la fraction de seconde près. On souhaite seulement que « cet (évènement|tache à exécuter) ai lieu approximativement (dans|toutes les) X seconde(s) ».
        
        Ainsi, si nous avions 10 pilotes de périphériques différents qui programmaient l'exécution d'une tâche toutes les secondes environ, mais n'avaient pas initialisé leurs timers en même temps (ou bien avec un intervalle légèrement différent), ils réveillaient le noyau 10 fois par seconde. Si ces 10 pilotes sont modifiés pour programmer leur réveil à une date arrondie avec round_jiffies, ils s'exécuteront en même temps, causant un seul réveil par seconde (un seul réveil à la seconde entière, qui, au passage, aurai de toutes façon eu lieu, même en l'absence de ces 10 pilotes, car il y a déjà d'autres choses converties au round_jiffies).
        
        Il reste beaucoup de travail pour tirer pleinement parti de cette nouvelle API partout où le noyau pourrait le faire, mais certains y travaillent visiblement, et chaque petite conversion réduit le nombre de réveils par seconde dont le noyau à besoin.
        
        Note : s'il y a des développeurs GTK/Gnome dans le coin : c'est exactement comme g_timeout_add_seconds_full() ou g_timeout_add_seconds() (au lieu de g_timeout_add()). Cette fonction permet d'économiser de l'énergie en réduisant les réveils de la CPU, car elle regroupe tout les évènements programmés à la prochaine seconde entière. Svp, si vous n'avez pas besoin d'une granularité/précision très fine, par ex. si vous avez besoin de programmer une action « approximativement toutes les X secondes », préférez utiliser celle-ci au lieu de g_timeout_add().
        
        [^]Re: CFS dans 2.6.23 !
        
        Posté par herodiade () le 12/07/2007 à 10:08. (lien). Évalué à 7.
        Ah et bien justement, on parle de ça dans l'édition du LWN ouverte au public aujourd'hui[1].
        
        Il serait vraiment intéressant que quelqu'un rédige un article sur la programmation économe en énergie pour linuxfr (ou mieux Linux Magazine) : utilisation des évènements plutôt que polls réguliers, utilisation de hal, de inotify ou de gamin, des timers regroupés, regroupement des accès aux block devices, réduction des animations graphiques (elles réveillent xorg), stracer régulièrement son application juste pour vérifier qu'elle ne fait vraiment rien lorsqu'elle est au repos, utiliser le système de notification d'Alsa (plutôt que poller le mixer), audit et disagnostic avec block_dump, strace, ltrace, powertop, lm-profiler et blktrace, ...
        
        Les ventes de portables par an ont maintenant dépassé les ventes de stations de bureau[2][3] : la consommation est donc devenue une problématique majeure pour le succès de « Linux sur le desktop ». Et Linux est une option considérée depuis peu avec beaucoup d'attention par les intégrateurs, maintenant - c'est récent - qu'ils disposent de chipsets x86 mobiles tout-en-un à très bas prix : le coût d'une licence Windows sur le portable final est dans ce cas proportionnellement très significatif. C'est probablement un critère déterminant dans le choix de Linux pour l'Asus EEPC, l'Intel Classmate ou encore l'OLPC, et de l'investissement d'Intel (qui commercialise de tels chipsets bons marché) qui paye des développeurs comme Arjan van de Ven pour travailler à plein temps sur la consommation électrique de Linux.
        
        Linux dispose d'une belle perspective pour s'imposer à travers ce nouveau marché des portables (en particulier des ultraportables à bas prix), mais il faut pour cela qu'on apprenne à programmer de façon économe. Jusqu'à présent, on ne considérait pas vraiment cet aspect spécifique, au coté, par exemple, des améliorations des performances ou de la consommation de mémoire vive. Mais les développeurs noyau essaient d'attirer notre attention sur ce sujet[4].
        
        [1] http://lwn.net/Articles/240253/ (voir aussi http://lwn.net/Articles/228143/ et http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0959.ht(...) ).
        [2] http://www.usatoday.com/tech/news/2005-01-23-laptop_x.htm
        [3] http://www.msnbc.msn.com/id/8090448
        [4] Je pense à PowerTOP d'Arjan van de Ven, mais aussi au fameux Why Userspace Sucks—Or 101 Really Dumb Things Your App Shouldn’t Do, Dave Jones (Red Hat), Proceedings of the Linux Symposium, 2006, Ottawa [https://ols2006.108.redhat.com/reprints/jones-reprint.pdf]

Scheduler

Posté par karteum59 () le 12/07/2007 à 08:01. (lien). Évalué à 2.

Qqun peut-il me dire pourquoi il ne serait pas possible d'utiliser la même base d'algorithmes de manière plus générique, à la fois pour le scheduler des processus, des IO, de la QoS réseau (tc), etc. ? Il existe déjà une pléthore d'algos (WFQ et autres), et il me semble (sauf erreur de ma part) qu'il y a de la similitude entre les problématiques de traffic shaping et de scheduling processus... Donc ne serait-il pas possible d'avoir une "libscheduler" dans le noyau qui puisse servir simultanément tout ça ?

Réciproquement, si je devais mettre en oeuvre un scheduler pour de la QoS réseau, est-il sensé d'imaginer copier-coller CFS de Ingo Molnar ? (ou un autre scheduler processus du noyau, mais je prends CFS pour exemple puisqu'il paraît qu'il est top :).

[^]Re: Scheduler

Posté par reno () le 12/07/2007 à 11:01. (lien). Évalué à 4.
Pas convaincu que ce soit bien utile: un algo de scheduling de processus doit s'occupper de la répartition de la charge entre les CPUs, des caches..

Pour les IO disques, il y a une gestion de localité tres importantes, mais pas pour le reseau..

Certes vu de loin ça fait la même chose, mais en pratique..

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Sortie du noyau Linux 2.6.22

Bravo !

[^]Re: Bravo !

[^]Re: Bravo !

[^]Re: Bravo !

[+] [^]Re: Bravo !

[^]Re: Bravo !

[^]Re: Bravo !

[^]Re: Bravo !

[^]Re: Bravo !

Merci !

[^]Re: Merci !

[^]Re: Merci !

Merci

erreur lien

Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

[^]Re: Fast forward

La même rengaine...

[^]Re: La même rengaine...

[^]Re: La même rengaine...

[^]Re: La même rengaine...

[^]Re: La même rengaine...

[^]Re: La même rengaine...

Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[^]Re: Fin de la branche CK

[+] [^]Re: Fin de la branche CK

Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[^]Re: Regressions et mac80211

[+] [^]Re: Regressions et mac80211

Support de Blackfin

[^]Re: Support de Blackfin

[^]Re: Support de Blackfin

[^]Re: Support de Blackfin

Merci

Qu'est-ce que « eventfd » ?

[^]Re: Qu'est-ce que « eventfd » ?

CFS dans 2.6.23 !

[^]Re: CFS dans 2.6.23 !

[^]Re: CFS dans 2.6.23 !