Noyau Sortie du noyau Linux 3.8

91
19
fév.
2013
Noyau

La sortie de la version stable 3.8 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence libre CC BY-SA).

À noter, une nouvelle survenue pendant le développement de cette version, dont l’incidence sur les développements futurs reste inconnue : Alan Cox, qui a été employé successivement par Red Hat et Intel, a décidé de quitter Intel et le développement du noyau (dont il est un des piliers) pour raisons familiales.

Merci aux participants à la rédaction de cette dépêche : Batchyx (notamment toute la partie Réseau), detail_pratique, yogitetradim, Spack, Ner’zhul, Étienne Bersac (notamment les parties « Optimisation pour architecture NUMA » et « Virtualisation »), Pierre Mazière, baud123, Xavier Claude, Akiel, Christophe Turbout, Strash et RbN.

Sommaire

La phase de test

RC-1 : beaucoup de commits et un peu de vin chaud

La version RC-1 a été annoncée par Linus le 21 décembre 2012 :

« La plus longue nuit de l’année est derrière nous¹, et quoi de mieux à faire que se prendre un bon vin chaud, s’installer confortablement, se relaxer et jouer avec la dernière RC du noyau ?

C’était une grande fenêtre de fusion : nous avons plus de commits que n’importe quel autre noyau de la série 3.x (cependant la version 3.2-rc1 était presque aussi importante). En d’autres mots, c’était une fenêtre de fusion mouvementée.

Diffstat semble normal : à peu près 63 % des patches sont dans les pilotes — staging, réseau, SCSI, GPU, audio, DRBD, etc. —, 18 % de mises à jour dans l’architecture (avec divers changements dans la plate‐forme ARM, qui constituent la plus grosse partie — soupir), et le reste vient de « divers », tels le cœur du réseau, les systèmes de fichiers (un nouveau système de fichiers, F2FS, optimisé pour les mémoires Flash) et des fichiers include.

Allez‐y, testez. »

Linus

⁽¹⁾ Et par « nous », je veux principalement dire les gens dans le même fuseau horaire et le même hémisphère que moi. Parce que je suis trop égocentrique pour me soucier des autres. »

RC-2 : une RC de taille raisonnable pour la nouvelle année

La version RC-2 est sortie le 2 janvier 2013 :

« C’est une nouvelle année, les gens retournent travailler, et essayent désespérément d’oublier toute la nourriture qu’ils ont ingurgitée en excès durant ces deux dernières semaines. Et eh, pour célébrer cela, voici la RC2 !

Le correctif est relativement petit, et largement dominé par les mises à jour pour processeurs graphiques et la suppression triviale de __devinit/exit dans la couche I²C. Mais il y a quelques travaux sur les systèmes de fichiers (ext4, eCryptfs, Ceph), et quelques correctifs de machines virtuelles ; ainsi que quelques tardifs nettoyages sur ARM OMAP.

Le résumé des modifications est en annexe, et mon « merge log » ressemble à ça :

Wolfram Sang : i2c __dev* suppression d’attributs
David Miller : Correctifs réseau
Eric Biederman : Correctifs d’espaces de noms
Guenter Roeck : Correctifs sur hwmon
Olof Johansson : Correctifs sur ARM SoC, tardifs nettoyages sur OMAP pour ARM
Dave Airlie : Mise à jour de DRM
Ted Ts’o : Correctifs de bogues sur ext4
Sage Weil : Correctifs sur Ceph
Tyler Hicks : Correctifs sur eCryptfs
Bjorn Helgaas : Mises à jour PCI
Wim Van Sebroeck : Correctifs sur watchdog
Bryan Wu : Correctifs sur LED

Allez‐y, testez. »

Linus

RC-3 : fin des vacances, une RC de taille raisonnable mais pas anodine pour autant

La version RC-3 est sortie le 9 janvier suivant :

« Les vacances sont terminées et les choses commencent à revenir à la normale. À l’exception de Greg, je suppose, qui doit probablement essayer de s’extraire de sa montagne de courriels.

Une nouvelle semaine, une nouvelle version candidate. De taille plutôt normale. La plupart des changements concernent des pilotes et sont répartis un peu partout pour effacer les dernières traces de __dev[init|exit], un tas d’entre eux étant d’une seule ligne .

Mais, à part ça, il y a de vraies mises à jour (les pilotes graphiques se distinguent — principalement Radeon et Exynos), du travail au niveau des architectures (ARM, PowerPC, MIPS et MicroBlaze), des systèmes de fichiers (F2FS, GFS, CIFS et NFS) et du réseau (Netfilter et Sun RPC).

Et j’espère vraiment que les choses vont se calmer. J’ai conscience qu’il y a eu des patches de vacances rejetés, mais essayons avant tout d’avoir une RC4 vraiment plus petite.
OK ? »

Linus

RC-4 : une RC calme qui sort le jour des enfants

La version RC-4 a été annoncée par Linus le 17 janvier :

« Salut, déjà une nouvelle semaine ! En fait, ça m’a tellement surpris que j’ai eu besoin d’un jour supplémentaire. Le concept “sortie en milieu de semaine” me semble bizarre.

Ceci m’a conduit à me demander quel était le jour le plus commun pour une sortie, et statistiquement, la plupart des sorties ont lieu un dimanche. L’“astuce Git de la semaine” ressemble à ça :

git log --no-walk --pretty="%ad" $(git tag -l)

qui peut ensuite être redirigé vers :

cut -d' ' -f1 | sort | uniq -c | sort -n

afin de voir l’ensemble des statistiques des étiquettes Git.

Cette digression mise à part, je peux joyeusement annoncer que la RC4 est plus petite que la RC3 malgré le jour supplémentaire, même s’il s’en faut de peu. Il n’y a pas vraiment grand‐chose qui sorte du lot : à part un nouveau pilote sans fil (le pilote Atheros Wilocity) et des changements OMAP DRM, le diffstat est plutôt plat et diffus. Ce qui signifie de nombreux petits changements un peu partout.

Le journal des modifications est joint, mais c’est en gros 85 % de pilotes, dont plus de la moitié se rapporte au nouveau pilote sans fil et aux changements OMAP DRM précités. Il y a également d’autres changements noyés dans la masse : de petites mises à jour ARM et S390 (plus des touches de SuperH et de x86), quelques petites corrections de systèmes de fichiers, des choses de ce genre.

Testez. Mon intuition est que les choses vont vraiment se calmer. Et je détesterais être contredit. »

Linus

RC-5 : avant la conférence Linux Australie

La version RC-5 est sortie le 25 janvier :

« Salut, Linux 3.8-rc5 est sorti. Donc, allez‐y !

Je voyagerai pour LCA — Linux Conference Australia — la semaine prochaine, j’espère donc que les choses se calmeront. Elles ne se sont pas trop calmées pour cette RC5, vu qu’on a encore plus de 300 commits pour cette version. Non pas que ces derniers soient tous inquiétants, mais il y a plus de mouvements sur Btrfs, F2FS, ptrace et dans le chargement des modules que ce que j’aurais préféré voir à ce stade.

Bien sûr, il y a aussi les classiques mises à jour de pilotes : i915 et Radeon, USB, série, etc. Mais ces pilotes représentent moins de la moitié des patches ce coup‐ci.

Allez‐y, testez. »

Linus

RC-6 : depuis l’Australie

La version RC-6 a été annoncée le 1ᵉʳ février :

« Voici la très attendue publication spéciale LCA, mais sans changement de mascotte cette fois. Elle n’est pas énorme, mais je veux vraiment que la RC7 soit plus petite, et je maudirai haut et fort quiconque m’enverra une requête d’ajout pour des choses que je ne considèrerai pas valables.

Il y a quelques mises à jour x86 et réseau, plus des changements au niveau du son et des pilotes graphiques Exynos qui montrent le bout de leur nez. Et de nombreuses autres choses dans des sous‐systèmes çà et là (pinctrl, regulator, IOMMU, NFS, DM/MD…).

Vous connaissez la chanson. »

RC-7 : sur le retour

La version RC-7 a été annoncée le 9 février :

« Une autre version d’Australie, juste avant de rentrer à la maison. Une fois de plus, cela n’a pas été aussi calme que ce que j’aurais souhaité (et avec l’épouvantable accès à Internet la semaine dernière, chaque récupération était assez pénible — Git utilise plutôt bien la bande passante, mais nécessite néanmoins un réseau qui tienne et ne perde pas de paquets à droite et à gauche). Bref, la voici. Surtout des mises à jour de pilotes (USB, réseau, Radeon, régulateur, son) avec quelques soupçons d’autres trucs (Btrfs, réseau, etc). Ça reste plutôt petit dans l’ensemble. »

Linus

Les nouveautés

i386 : car c’est un bon camaraaaadeu

La prise en charge des processeurs i386 a été retirée du noyau à l’initiative d’Ingo Molnar (comme ça, vous avez le nom du coupable à châtier ; mais attention, il n’est pas seul, c’est une décision collégiale des mainteneurs x86). Le point d’entrée en termes d’ancienneté, s’agissant de l’architecture x86, devient donc de fait le i486.

Mine de rien, c’est tout un symbole : il s’agit de l’architecture sur laquelle Linus Torvalds a créé Linux en 1991. Toutefois, ce dernier n’a pas montré de sentimentalisme excessif (ce qui n’est de toute façon pas son genre) et lui a souhaité bon vent.

À noter qu’Intel a cessé de commercialiser ces puces en 2007.

Cette nouveauté nous donne l’occasion de nous replonger dans le passé du noyau et de sa prise en charge progressive d’un nombre toujours plus grand d’architectures processeur :

Optimisation pour architecture NUMA

Les architectures NUMA, où chaque processeur a un contrôleur mémoire dédié, nécessitent une révision de l’ordonnanceur. En effet, l’ordonnanceur doit tenir compte de la topologie du processeur pour placer un processus sur le cœur le plus proche de sa mémoire. L’ordonnanceur actuel est trop naïf pour ces architectures, ce qui provoque des pertes de performance.

Linux 3.8 apporte une première étape dans la prise en charge correcte de ces architectures. Ce ne fut pas facile, car ce sujet touche à deux domaines traditionnellement distincts : la mémoire et le processeur. Les équipes respectives se sont donc chamaillées pendant quelques semaines avant d’aboutir à un premier jalon.

Seules les fondations pour une prise en charge automatique du NUMA ont été posées. Les prochaines versions du noyau devraient donc voir l’arrivée d’ordonnanceurs automatiques pour architecture NUMA. Chaque équipe devrait proposer sa solution, plutôt orientée gestion de la mémoire ou du processeur. Le plus optimal l’emportera.

Prise en charge préliminaire du futur processeur IBM POWER8

Alors que le processeur IBM POWER8 est annoncé pour succéder cette année (dans les serveurs haut de gamme IBM) au POWER7 — qui était à l’honneur notamment dans les dépêches des versions 2.6.27 et 2.6.36 du noyau —, celui‐ci intègre dès à présent une prise en charge préliminaire de ce processeur.

Le POWER8 sera gravé en 22 nm et proposera notamment un simultaneous multithreading (SMT) de quatrième génération.

Pour rappel, la feuille de route d’IBM est conçue sur la base d’une refonte majeure de la conception du processeur tous les trois ans (ex : POWER7), avec à la mi‐étape un raffinement des méthodes de gravure et quelques changements modestes d’architecture (ex : POWER7+), à la façon de la stratégie tic‐tac d’Intel.

Pilote graphique pour Nvidia Tegra 2/3

Bien que la version 2.6.36 du noyau ajoutât la prise en charge du cœur processeur ARM du Tegra (et que, récemment, la version 3.4 ajoutât celle du Tegra 3), il manquait dans tous les cas la prise en charge de la partie graphique de ces système monopuce (SoC). Dorénavant, Linux embarque un pilote graphique basique (pour l’instant limité à la 2D) pour les SoC Tegra 2 et Tegra 3. Une fois n’est pas coutume, ce pilote est développé avec la collaboration du concepteur Nvidia (qui ne va pas pour autant jusqu’à le développer lui‐même : fuck).

Nouveau système de fichiers pour mémoires Flash : F2FS

Le nouveau système de fichiers F2FS (sigle pour Flash-Friendly File-System) qui fait son apparition dans cette version du noyau a été spécialement conçu par Samsung pour les appareils utilisant de la mémoire Flash, comme les clés USB, cartes mémoires et tous les appareils embarquant ce type de mémoire (tablette, smartphone…).

Ce n’est pas le premier système de fichiers à avoir cet objectif (citons YAFFS, JFFS2, LogFS ou encore UBIFS) : l’avenir nous dira si le succès est au rendez‐vous. Ce nouveau système de fichiers cible certaines mémoires Flash embarquées, et non les disques SSD. Les mémoires ciblées contiennent un contrôleur FTL, conçu pour implémenter dans le matériel l’optimisation de mémoire Flash que des système de fichiers comme FAT n’ont pas.

À noter que Microsoft promeut dorénavant à cet effet exFAT (pour Extended File Allocation Table), un système de fichiers propriétaire et breveté développé en 2006 (au lieu de l’antique FAT32 limité aux fichiers de moins de 4 Gio). Ainsi, la norme des cartes mémoire SDXC (qui doivent succéder aux cartes SDHC) prévoit que celles‐ci soient formatées par défaut en exFAT. Sous Linux, il existe depuis peu un pilote libre en espace utilisateur (fuse-exfat), sous licence GPL v3, gérant ce système de fichiers.

Les améliorations

Chiffrement plus rapide

Il existe différents algorithmes de chiffrement inclus dans le noyau Linux, tels que Camellia, CAST5, Serpent, Twofish et CAST6.

Afin de rendre leur usage le plus transparent possible pour l’utilisateur et de permettre leur généralisation, il est essentiel que ces algorithmes soient performants et tirent profit au mieux des possibilités matérielles.

Les précédentes versions du noyau ont connu un certain nombre d’optimisations dont nous nous sommes fait le relai :

  • code assembleur optimisé x86_64 de Twofish et Blowfish (Linux 3.2) ;
  • code assembleur optimisé SSE2 et x86-64 de Serpent (Linux 3.3) ;
  • code assembleur optimisé x86-64 de Camellia (Linux 3.4) ;
  • code assembleur optimisé AVX de Serpent et Twofish (Linux 3.6).

Cette nouvelle version du noyau apporte de nouvelles optimisations :

  • optimisation de Camellia pour les jeux d’instructions AES-NI, AVX et x86_64 ;
  • optimisation de CAST5, Serpent, Twofish et CAST6 pour le jeu d’instructions AVX.

Pilotes graphiques pour vos PC

Intel

Les nouveautés couvrent ici principalement la stabilisation des pilotes pour deux architectures qui forment quasiment les deux bouts de la chaîne de puces graphiques du fondeur : l’antique Gen2 et le pas-encore-sorti Haswell, mais aussi la correction d’un bogue qui créait des artefacts visuels avec les dernières générations (Gen6+) :

  • Prise en charge a priori stable de la partie graphique de Haswell (le successeur à venir de Ivy Bridge) ;
  • Avec cette version du noyau et les pilotes ad hoc (v 2.20.12 ou supérieure), les utilisateurs de puces graphiques Intel Sandy Bridge (Gen6) et Ivy Bridge (Gen7) devraient finalement être débarrassés d’un défaut qui aura donné bien du fil à retordre aux développeurs : le tearing (des parties de l’image se scindent en bandes horizontales qui apparaissent décalées les unes par rapport aux autres pendant un court laps de temps, voir le rapport de bogue correspondant) ;
  • Stabilisation des pilotes des puces i830/i845 (Gen2) commercialisées au début des années 2000 : ceux‐ci n’avaient pas vraiment apprécié le passage à l’architecture Graphics Execution Manager en 2008. Cette version du noyau, couplée avec les pilotes ad hoc (v 2.20.16 ou supérieure), règle tout cela ! Certains diront qu’Intel aura pris son temps, d’autres salueront le fait qu’Intel, non content de fournir uniquement des pilotes Linux libres pour ses puces graphiques, continue d’optimiser ses pilotes pour ses très anciennes puces.

Nouveau (pilote libre pour puces Nvidia)

La grande Nouveau‐té est que cette version du noyau permet désormais la prise en charge (2D, et 3D dans la limite de Gallium3D) de toutes les puces Nvidia, même les plus récentes (Fermi, Kepler…). Le temps que ce noyau fasse son chemin dans les différentes distributions et l’expérience utilisateur sera tout à fait confortable par défaut. Un grand bravo à l’équipe de Nouveau qui, rappelons‐le, développe entièrement par rétro‐ingénierie.

Les efforts pour permettre la gestion automatique du ventilateur, initiée lors de la version précédente du noyau, se poursuivent mais n’ont hélas pu aboutir pour cette version : croisons les doigts pour la prochaine ! De même pour le changement de fréquence — reclocking.

Le Z-buffer permet de ne calculer que la partie rendue à l’écran pour économiser notamment la bande passante. Il semble que seules les puces de génération nv20 en tiraient partie jusqu’à présent. Dorénavant les générations nv30 (GeForce 5/FX) et nv40 (GeForce 6 et 7) en profitent aussi.

Radeon (pilote libre pour puces ATI/AMD)

AMD continue de publier tout doucement les spécifications de ses puces, de sorte que la nouvelle version du noyau prend en charge les transferts de mémoire asynchrones (afin de pouvoir charger les informations en mémoire même lorsque les unités de calcul des shaders sont occupées à faire le rendu). Ceci pour les puces R600 et supérieures (voir ici et ). Il reste toutefois à mesurer les bénéfices pratiques de cette fonctionnalité (avec la version adéquate du pilote 3D).

Systèmes de fichiers Btrfs et ext4

Cette version du noyau ajoute un système de fichiers spécialisé, ainsi que nous l’avons vu. Mais qu’en est‐il des systèmes généralistes ?

Pour faire court, des modifications apportées à Btrfs (toujours considéré comme expérimental) le rendent plus rapide dans certaines conditions (voir les notes de Chris Mason à ce sujet), tandis que celles apportées à ext4 le rendent plus efficace avec des fichiers de petite taille en les stockant avec les nœuds d’index — inodes — (lire les notes de Ted Ts’o) à ce sujet.

Réseau

Pour cette version, les nouveautés (lire ici et ) sont plus limitées que dans la précédente.

Netlink

Netlink est une interface de communication entre le noyau et des processus en espace utilisateur présente depuis le noyau 2.2. Elle sert principalement à examiner, configurer et surveiller les données réseau comme les adresses IP, les tables de routage et autres paramètres. Cette interface, plus récente et moderne que la myriade d’ioctl (qu’utilisent encore les vénérables ifconfig et route), possède de nouvelles fonctionnalités dans cette version 3.8.

Il est désormais possible d’examiner, surveiller et modifier la base de données multicast des ponts réseau — bridges. C’est la table qu’utilise le noyau lorsqu’il reçoit une trame multicast sur un pont réseau pour savoir vers quels ports la trame doit être renvoyée. Toujours sur les ponts réseau, il est maintenant possible de modifier tous les paramètres via Netlink, de quoi rendre obsolète le programme brctl.

Autre nouveauté pour le multicast, mais niveau IP cette fois : l’implémentation du routage multicast IPv4 et IPv6 a été dépoussiérée, et il est maintenant possible d’examiner l’état du routage multicast via Netlink.

Une nouvelle interface permettant de modifier les paramètres réseau, auparavant présents sous forme de sysctl, a été intégrée dans ce noyau. Pour l’instant, seuls les paramètres forwarding (permettant d’activer le routage entre interfaces) et rp_filter (permettant d’activer le filtrage de l’adresse source) peuvent être modifiés et surveillés via Netlink.

La gestion de ces nouvelles fonctionnalités a bien sûr été ajoutée dans le programme iproute2, l’utilisateur principal de Netlink, qui fournit les commandes ip address, ip route et autres pour configurer le réseau de manière moderne. Ce programme utilise exclusivement les interfaces Netlink lorsqu’elles sont disponibles et sinon utilise des appels à ioctl().

Notamment, avant ce noyau 3.8, certains types de tunnels ne pouvaient pas être créés via Netlink. C’est maintenant corrigé, et cela permettra d’éliminer quelques appels à ioctl() lorsque l’on utilise ip tunnel.

Espace de nom réseau en tant qu’utilisateur

La fonctionnalité permettant de créer une pile réseau virtuelle pour isoler les interfaces et configurations réseau les unes des autres a gagné une fonctionnalité supplémentaire : il n’est plus nécessaire d’être root pour créer un espace de noms réseau — network namespace.

Un utilisateur simple pourra donc créer un espace de noms réseau, créer des interfaces virtuelles, configurer des adresses IP, ses tables de routages, son pare‐feu Netfilter (via iptables) et bien d’autres fonctionnalités, dans un environnement séparé. Comme avant, les cartes réseau originales ne pourront pas être modifiées ou utilisées dans le nouvel espace de noms, sauf si l’administrateur décide de les déplacer.

Concrètement, un processus qui crée un nouvel espace de noms réseau sera coupé du réseau physique, et pourra créer des interfaces virtuelles comme s’il était administrateur d’une machine virtuelle sans lien avec l’hôte. Mais, pour tout le reste, il restera un processus dans la machine hôte.

Pour créer un espace de noms réseau en tant qu’utilisateur, un processus devra créer un espace de noms d’utilisateurs où il se placera en tant que « super‐utilisateur virtuel ».

Les mount namespaces, les pid namespaces et les user namespaces ont aussi été modifiés pour être gérés en tant que simple utilisateur.

Wi‐Fi 802.11

Dans ce noyau apparaît un pilote pour les puces Wilocity 6210. Il s’agit du premier pilote Linux d’un matériel utilisant le standard 802.11ad. Ce standard, basé sur Wi‐Fi mais baptisé WiGig, permet en utilisant une bande de fréquences à 60 GHz, d’obtenir des débits allant jusqu’à 7 Gbit/s, mais sur des distances réduites par rapport à un réseau Wi‐Fi classique.

Ce noyau marque également le début de la gestion du standard 802.11ac. Ce standard, plus dans la continuité du Wi‐Fi 802.11n, permet des débits de 500 Mbit/s à 1 Gbit/s, notamment en permettant d’utiliser des canaux plus larges. Aucun pilote de périphérique gérant ce standard n’est pour l’instant intégré dans ce noyau, et cette fonctionnalité reste pour le moment expérimentale.

Protection contre les attaques TCP aveugles.

Le noyau 3.8 implémente maintenant le standard RFC 5961 qui vise à mitiger certaines attaques aveugles contre TCP, qui peuvent permettre à un attaquant de terminer une connexion voire d’injecter des données dans le flux. La faiblesse vient des numéros de séquence de TCP. Un attaquant cherchant à couper une connexion TCP sans avoir accès au contenu de la connexion a besoin de deviner un numéro de séquence valide. Or, un numéro de séquence valide n’a pas besoin de correspondre exactement à la valeur attendue, mais peut être légèrement supérieur, jusqu’à une valeur Receive Window, négociée lors de l’établissement de la connexion. Mais, la taille de cette fenêtre n’a cessé de croître avec le temps pour augmenter les performances, ce qui fait qu’un attaquant peut deviner un numéro de séquence plus facilement.

Pour éviter ces attaques, la RFC 5961, maintenant implémentée dans ce noyau 3.8, recommande de ne pas accepter les demandes de coupure de connexion qui ne tombent pas exactement sur la valeur attendue, mais à la place, de renvoyer un paquet ACK contenant le numéro de séquence attendu. Si la demande était légitime, alors le pair renverra une demande avec un numéro de séquence exact, garantissant sa légitimité. Comme cela ne change pas le protocole TCP, cette solution peut être implémentée dans ce noyau sans casser la compatibilité avec les autres systèmes.

Autres nouveautés

D’autres petites nouveautés sont apparues dans ce noyau ; Linux gère maintenant les cartes réseau capables de calculer les sommes de contrôles de paquets encapsulés dans des tunnels. Il est maintenant possible de filtrer en fonction du réseau local virtuel (VLAN) dans un filtre Berkeley, le traduction d’adresses réseau (NAT) gère mieux les changements de routages et le noyau gère maintenant les extensions DOVE pour VXLAN, qui permettent d’utiliser VXLAN sans multicast IP.

Virtualisation

La prise en charge des architectures ARM par KVM a été repoussée. Peut‐être pour la 3.9 ?

Deux fonctionnalités importantes pour le conteneur sont disponibles dans cette version : la limitation de la mémoire noyau pour un cgroup et les espaces de noms utilisateur.

Limitation de la mémoire noyau

Les contraintes d’utilisation mémoire d’un cgroup concernent maintenant également la mémoire noyau. Cela permet de confiner les attaques de type « fork‐bomb » ou des congestions réseau à un conteneur.

Espace de noms utilisateur

Le but est de ne pas considérer l’utilisateur root d’un conteneur comme le root de l’hôte. Cela se fait par une table de correspondance associée au processus. On peut lire cette table dans /proc/PID/uid_map. Les groupes sont évidemment gérés de la même manière.

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.8, le total des patches s’établit à 12 394, alors qu’il était de 11 990 pour le noyau précédent. C’est à nouveau un chiffre très élevé, même si l’on compare aux précédentes versions en remontant assez loin.
L’accroissement net du nombre de lignes de code est d’environ 225 000.

Selon les statistiques du site remword, 1 305 personnes différentes ont participé à l’écriture des patches de ce nouveau noyau (1 316 développeurs pour le précédent). Le contributeur le plus prolifique est encore une fois H. Hartley Sweeten avec 426 patches (soit 3,44 %). Mais si l’on tient compte du nombre de lignes de code, il s’agit alors de Greg Kroah‐Hartman (47 613 lignes, soit 5,21 %, en 80 patches) et H. Hartley Sweeten n’est plus « que » deuxième (37 580 lignes, soit 4,11 %).

À suivre avec la version 3.9…

  • # OpenCL, Intel, hem...

    Posté par . Évalué à  2 .

    Toujours pas de support d'OpenCL pour le pilotes Intel. :(

    • [^] # Re: OpenCL, Intel, hem...

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

      peux-tu élaborer ?

      Fais-tu référence à http://linuxfr.org/users/zezinho/journaux/un-nouveau-joli-testeur-de-carte-graphique-proprietaire-pour-linux-unigine-valley qui montre qu'Intel fait peut-être d'abord de l'open-source pour les pilotes graphiques sous Linux, mais parfois d'abord du propriétaire sous d'autres OS ? (pas forcément dans cet ordre).

      • [^] # Re: OpenCL, Intel, hem...

        Posté par . Évalué à  3 .

        Je faisait juste référence à l'absence de support de l'OpenCL dans le pilote libre pour les cartes graphiques Intel. Il n'y a aucune sous-entendu là dedans.

        • [^] # Re: OpenCL, Intel, hem...

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

          Il n'y a aucun sous-entendu là dedans.

          un peu tout de même : OpenCL permet d'utiliser le GPU en supplément du CPU. Intel le permet sous d'autres systèmes que Linux ?

          • [^] # Re: OpenCL, Intel, hem...

            Posté par . Évalué à  1 .

            Intel le permet sous d'autres systèmes que Linux ?

            C'est hors propos. La news parle du Kernel Linux et j'en fais de même.

            • [^] # Re: OpenCL, Intel, hem...

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

              Ma question naïve, t'aurait permis d'indiquer ce que tu souhaitais en faire sous Linux, quelles applis en bénéficient ou auraient pu en bénéficier (en libre, tu auras traduit). Visiblement, tu es insatisfait, reviens à la prochaine version :-) En indiquant ce que tu en attends, cela peut permettre d'indiquer ce que cela apporte (j'en ai quelques idées, outre BOINC mais je préférerais que tu parles de tes utilisations).

              • [^] # Re: OpenCL, Intel, hem...

                Posté par . Évalué à  5 .

                C'est surtout pour être utilisé avec des applications comme Darktable ou les futures versions de GIMP.

                • [^] # Re: OpenCL, Intel, hem...

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

                  Cela sert à quoi, concrètement ? Passer par le CPU fournit la fonction, en quoi utiliser le GPU améliore les choses. Bon, j'arrête de te prendre par la main, si tu ne sais pas dire ce que ça apporte, c'est que tu t'en passes sous Linux (alors que cela pourrait apporter pas mal de choses, si tu ne veux pas en parler, c'est ton problème, moi je n'en ai pas le besoin :D).

                  Et pourtant, je connais bien les traitements graphiques (c'est particulièrement intéressant et plus complexe que ceux que certains croient, cf. gmic) : comment les utiliserais-tu, qu'est-ce que cela te permettrait de faire que tu ne peux faire aujourd'hui ?

                  • [^] # Re: OpenCL, Intel, hem...

                    Posté par . Évalué à  5 .

                    Il n'est pas nécessaire de donner autant de détails.
                    Si tu connais aussi bien domaine du traitement graphique que tu le dis, tu connais les avantages que cela apporte.

                    • [^] # Re: OpenCL, Intel, hem...

                      Posté par . Évalué à  7 . Dernière modification : le 20/02/13 à 11:54

                      Perso j'essaie d'apprendre openCL pour paralléliser des calculs. Je m'en sors en utilisant les pthreads sur mes 4 cœurs mais mais je voudrais bien utiliser le GPU pour accélérer ça encore plus. En plus openCL permet d'accélérer les transformées de Fourier, ce que les autres systèmes pour paralléliser les boucles (p.ex. pthreads, openMP) ne font pas. J'ai essayé fftw/gsl/lapack/mkl mais ça devient embêtant d'utiliser autant d'API différentes. Il y a aussi la solution CUDA mais le code devient non portable (uniquement NVidia, et en plus il faut investir dans une carte graphique de cette marque). OpenCL utilise automatiquement tous les cœurs de CPU et GPU disponibles, quels que soient la marque, dès lors qu'un driver/SDK est installé et les implémente. L'objectif ultime est que openCL me permette d'utiliser les 4 cœurs CPU + ma carte ATI + le GPU Intel intégré à la carte mère.

                      • [^] # Re: OpenCL, Intel, hem...

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

                        Je ne comprend pas du tout ce que tu racontes sur le fait que que OpenCL permet d'optimiser les transformée de fourier contrairement à pthreads ou openMP.

                        OpenCL n'a rien de magique. Tout ce que tu peux faire avec OpenCL peut être fait avec n'importe quel api à base de thread sur CPU (TBB, openMP, pthread). Et tout ce que tu peux faire sur GPU se fait avec une autre API comme OpenGL ou DirectX. C'est juste une façon de programmer différente.

                        Ce qui fait la force d'openCL c'est que c'est le seul outil qui tourne autant sur CPU que sur GPU de façon unifiée. Maintenant cela ne veut pas dire que c'est transparent (en pratique il faut souvent écrire un code différent pour CPU et pour GPU), et il faut soit même faire la répartition du travail entre le CPU et le GPU (ainsi que les synchronisations/ transferts, …).

                        Bref, openCL est une très belle techno (malheureusement qui a du mal à s'imposer face à cuda), mais ce n'est pas un truc magique qui accélère l'internet et fait le café.

                        • [^] # Re: OpenCL, Intel, hem...

                          Posté par . Évalué à  4 .

                          Je ne comprend pas du tout ce que tu racontes sur le fait que que OpenCL permet d'optimiser les transformée de fourier contrairement à pthreads ou openMP.
                          OpenCL n'a rien de magique. Tout ce que tu peux faire avec OpenCL peut être fait avec n'importe quel api à base de thread sur CPU (TBB, openMP, pthread).

                          Souvent les GPUs exposent des instructions hardware permettant d'optimiser les rendus graphiques, il est peut-être possible d'en tirer parti pour faire une transformée de Fourier accélérée. Après je connais pas assez quelles instructions hardware sont disponibles pour pouvoir dire si c'est effectivement le cas, mais en tout cas on peut faire des choses différemment sur le GPU.

                          Et tout ce que tu peux faire sur GPU se fait avec une autre API comme OpenGL ou DirectX. C'est juste une façon de programmer différente.

                          C'est sûr, mais pour y avoir goûté ça pique vraiment, donc ça se comprend qu'on ait envie d'avoir un driver OpenCL plutôt que de devoir jouer avec des framebuffer objects, des textures, du glsl…

                          • [^] # Re: OpenCL, Intel, hem...

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

                            Souvent les GPUs exposent des instructions hardware permettant d'optimiser les rendus graphiques, il est peut-être possible d'en tirer parti pour faire une transformée de Fourier accélérée.

                            Je me suis mal exprimé. Tout à fait d'accord que certains problèmes (typiquement une transformé de fourier) sont plus adaptés à un GPU qu'un CPU, mais cela ne veut pas dire que ce n'est pas optimisable sur CPU et que le jeux n'en vaut pas la chandelle. En ce moment on assiste à une grande passion pour le GPU, mais si les développeurs passaient autant de temps à optimiser pour CPU qu'il le font pour GPU, beaucoup de code CPU tourneraient bien plus vite.

                            Programmer pour GPU c'est globalement faire du C avec d’énormes contraintes. Du C où tu sais comment les données sont disposées en mémoire, du C où tu sais comment la machine charge les données. Du C où tu essayes de ne pas faire de if parce que c'est mal. Du C où tu n'aimes pas les accès aléatoire au données. Du C où tu fais toi même les copies entre la ram et le cache parce que la machine ne le fait pas pour toi. Du C sans fonctions récursives. Du C sans types "pratiques" (les doubles… LOL…).

                            Les instructions hardware disponibles dans un GPU sont souvent liées au pipeline graphique (globalement: remplir des triangles), qui n'est pas exposé dans OpenCL.

                            En pratique ce que va t'exposer OpenCL c'est certaines fonctions optimisées ou calculs vectoriels, mais tout cela est aussi disponible sur un bon CPU (sse/avx). Le truc c'est qu'avec un peu de chance, sur CPU ton compilateur va savoir exploiter cela tout seul, sur GPU il faut le faire à la main.

                            Ce qui fait la différence entre un GPU et un CPU c'est que l'architecture est différente, ainsi en fonction du type de problème à traiter, il est clair qu'un GPU sera plus adapté et pourra roxer à mort du pinguin en performance (en fait tout les problèmes qui peuvent se décomposer en une grosse quantité de sous problèmes identiques et indépendants nececitant beaucoup de calcul et générant peu de transactions mémoire).

                            Donc un GPU n'est pas une bête simple à domestiquer et un code "naïf" sur GPU ne va pas donner grand chose comparé au même code naïf sur CPU.

                            C'est sûr, mais pour y avoir goûté ça pique vraiment, donc ça se comprend qu'on ait envie d'avoir un driver OpenCL plutôt que de devoir jouer avec des framebuffer objects, des textures, du glsl…

                            Essayes OpenCL… C'est la même chose, tu remplaces les framebuffer objects par des buffer objects, les textures par des images et le glsl par de l'OpenCl ;) C'est juste plus générique et permet de cibler avec le même code deux plateformes hétérogènes (CPU et GPU), mais ce n'est finalement pas si simble.

                            tl/dr: Le GPU c'est cool. J'aimerais bien avoir OpenCL disponible de partout sans me poser de question, mais s'il vous plait, arrêter de brandir le mot GPU de partout en disant que cela va sauver le monde et que c'est la solution à tout les problèmes, après il y a des décideurs qui écoutent…

                  • [^] # Re: OpenCL, Intel, hem...

                    Posté par . Évalué à  3 .

                    Bon, j'arrête de te prendre par la main

                    C'est pas lui qui sait pas, c'est toi. Tu n'as qu'à chercher par toi même.
                    On va pas ré-expliquer une technologie connue à chaque fois qu'on la mentionne dans un message.

    • [^] # Re: OpenCL, Intel, hem...

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

      rien de rien d'annoncé à ce sujet hélas, par contre OGL 3.3 en bonne voie et OGLES 3.0 acquis

  • # Merci !

    Posté par . Évalué à  10 .

    J'ai pas l'occasion de suivre les news sur le kernel, de fait j’apprécie beaucoup les résumés qui sont publié ici.
    Merci et continuez le bon boulot =)

  • # Coquille

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

    Les architectures NUMA, où chaque processeur a un contrôleur mémoire dédié, nécessite

    nécessitent

    • [^] # Re: Coquille

      Posté par . Évalué à  3 .

      L'autre coquille, c'est que les architectures NUMA n'ont pas forcément un controleur par processeur. Les Opteron et Intel (depuis Nehalem) ont un controleur mémoire intégré. Mais avant, quand le controleur n'était pas intégré, il pouvait y avoir plusieurs processeurs autour de chacun des controleurs. IBM, SGI et Bull notamment, ont longtemps fait des grosses machines NUMA comme ça, avec par exemple 2 ou 4 Itanium ou Xeon pre-Nehalem autour de chaque controleur.

  • # tearing et gen6

    Posté par . Évalué à  1 .

    Just une précision, pour le tearing et les intel graphics gen6 le problème n'est pas encore vraiment résolu: c'est juste les infrastructures qui sont en place pour une vsync sans trop de perte de performance (et peut-être pas pour les premières révisions des gen6 sandy bridge si je me souviens bien).

  • # Nouveau…

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

    Les efforts pour permettre la gestion automatique du ventilateur, initiée lors de la version précédente du noyau, se poursuivent mais n'ont hélas pu aboutir pour cette version : croisons les doigts pour la prochaine ! De même pour le reclocking.

    Diantre! Je comptais utiliser Nouveau à partir de Linux 3.8, mais je pense que je vais attendre la 3.9. :/

    Le Z-buffer permet de ne calculer que la partie rendue à l'écran pour économiser notamment la bande passante. Il semble que seules les puces de génération nv20 en tiraient partie jusqu’à présent. Dorénavant les générations nv30 (GeForce 5/FX) et nv40 (GeForce 6 et 7) en profitent aussi.

    Sacrebleu! Pas encore pour moi… (j'ai une NV50) :(

    Mais au moins:

    La grande Nouveau-té est que cette version du noyau permet désormais la prise en charge (2D, et 3D dans la limite de Gallium3D) de toutes les puces Nvidia, même les plus récentes (Fermi, Kepler…). Le temps que ce noyau fasse son chemin dans les différentes distributions et l'expérience utilisateur sera tout à fait confortable par défaut. Un grand bravo à l'équipe de Nouveau qui, rappelons-le, développe entièrement par rétro-ingénierie.

    J'espère que cela donnera la visibilité et le succès que le projet mérite. Et n'oubliez pas de les aider en utilisant REnouveau.

    Texte écrit en Bépo selon l'orthographe de 1990.

    • [^] # Re: Nouveau…

      Posté par (page perso) . Évalué à  10 . Dernière modification : le 20/02/13 à 02:26

      Diantre! Je comptais utiliser Nouveau à partir de Linux 3.8, mais je pense que je vais attendre la 3.9. :/

      Désolé, c'est un peu de ma faute mais c'est aussi dû au fait que j'ai pas réussi à convaincre le mainteneur de la stabilité de mon code. Du coup, il a maturé durant quelques mois sur notre branche perso et a eu quelques corrections de bugs, notamment pour les nv40 :)

      J'espère que cela donnera la visibilité et le succès que le projet mérite. Et n'oubliez pas de les aider en utilisant REnouveau.

      Pitié, faut oublier REnouveau. On a en plus besoin depuis des années :)

      • [^] # Re: Nouveau…

        Posté par . Évalué à  10 .

        Met un gros DEPRECATED sur la page freedesktop.org ci-dessus :)

      • [^] # Re: Nouveau…

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

        Désolé, c'est un peu de ma faute mais c'est aussi dû au fait que j'ai pas réussi à convaincre le mainteneur de la stabilité de mon code. Du coup, il a maturé durant quelques mois sur notre branche perso et a eu quelques corrections de bugs, notamment pour les nv40 :)

        Tu veux dire que c'est grâce à toi qu'on a nouveau, non? :)

        Pitié, faut oublier REnouveau. On a en plus besoin depuis des années :)

        Mettre l'avertissement en haut de page et plus visible alors, je l'avais pas vu! Faut dire que j'ai pas exploré la page non plus…

        Texte écrit en Bépo selon l'orthographe de 1990.

  • # LXC

    Posté par . Évalué à  10 .

    Même pas le temps de lire la new qu'il est déjà là, à attendre d'être compilé :)

    ls /usr/src 
    linux@  linux-3.7.8-gentoo/  linux-3.8.0-gentoo/  rpm/
    
    

    Les mount namespace, les pid namespaces et les user namespaces ont aussi été patchés pour être gérés en tant qu'utilisateur simple.

    Donc on pourra lancer un conteneur LXC facilement sans être root ?
    Et avec l'arrivé des user namespaces y'a plus grand-chose comme "défaut" à LXC non ?

  • # Statistiques étranges

    Posté par . Évalué à  2 .

    Mais si l'on tient compte du nombre de lignes de code, il s'agit alors de Greg Kroah-Hartman ( 47 613 lignes soit 5.21%, en 80 patches) et H. Hartley Sweeten n'est plus « que » deuxième ( 37 580 lignes soit 4.11%).

    Soit environ 600 lignes de code par jour pendant les 68 jours qui séparent cette version de la précédente.
    Même si c'est le nombre de lignes des diffs, admettons.

    • [^] # Re: Statistiques étranges

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

      Ce n'est pas forcément le nombre de ligne de code qu'ils ont écrit en 68 jours, c'est le nombre de ligne de code qui sont rentrés dans le noyau de linus :). Certains patchs peuvent être à priori plus vieux, tout dépend combien de temps / étapes ils ont mis avant d'arriver dans le noyau mainstream.

  • # Désolé les mouches

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

    Le nouveau système de fichiers F2FS (acronyme de Flash-Friendly File-System)…

    Je vais faire mon chieur, mais F2FS n'est pas un acronyme, mais un sigle. Je ne sais pas pourquoi, plus personne n'utilise le mot sigle, il n'y a plus que des acronymes. Pourtant, ce sont deux choses différentes.

    Un acronyme, comme son nom l'indique, est un sigle qui se prononce comme un mot, plutôt que d'énoncer les lettres unes à unes.

    Exemple : GNOME est un acronyme, KDE est un sigle.

    C'est tout pour aujourd'hui.

  • # Désolé les mouches

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

    Le nouveau système de fichiers F2FS (acronyme de Flash-Friendly File-System)…

    Je vais faire mon chieur, mais F2FS n'est pas un acronyme, mais un sigle. Je ne sais pas pourquoi, plus personne n'utilise le mot sigle, il n'y a plus que des acronymes. Pourtant, ce sont deux choses différentes.

    Un acronyme, comme son nom l'indique, est un sigle qui se prononce comme un mot, plutôt que d'énoncer les lettres unes à unes.

    Exemple : GNOME est un acronyme, KDE est un sigle.

    C'est tout pour aujourd'hui.

  • # .

    Posté par (page perso) . Évalué à  -4 . Dernière modification : le 20/02/13 à 02:48

    .

    • [^] # celui-ci aussi

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

      Pâle tentative de modif (on ne peut pas effacer le post dans le temps imparti pour le modifier ?).

      • [^] # Re: celui-ci aussi

        Posté par . Évalué à  10 .

        Nope. Ça permet de savoir que untel a écrit une connerie et s'est ravisé. :)

  • # RFC5691 vs RFC5961

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

    Dans le texte, il y a une typo sur le numéro de la RFC, il s'agit de la RFC5961 et non RFC5691.

    Je me demandais au passage si cette technique n'engendrait pas de nouveaux problèmes. Je n'ai pas le temps de lire cette RFC tout de suite, et donc quand je lis "mais à la place de renvoyer un paquet ACK contenant le numéro de séquence attendu", je me demande si un attaquant ne peut pas créer un flood d'envoi de paquets ACK du serveur au client initial. Enfin, je ne suis pas sûr de comprendre vraiment l'idée en fait :). Quid des performances ?

    • [^] # Re: RFC5691 vs RFC5961

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

      Corrigé, merci.

    • [^] # Re: RFC5691 vs RFC5961

      Posté par . Évalué à  3 . Dernière modification : le 20/02/13 à 17:18

      Ça m'apprendra à m'y prendre quelques jours avant la sortie ;)

      Pour les ACK bidons, il faut savoir quel but tu veut atteindre.

      Si tu veux couper la connexion et que l'un des deux pair légitimes cherche à couper la connexion, je vois pas pourquoi tu aurai envie de balancer des ack bidons, rien faire est parfaitement suffisant. Les acks bidons risquent plus d'empêcher la fermeture de la connexion qu'autre chose ;)

      l'ACK que tu envoie quand tu détecte le RST litigieux est un ACK TCP parfaitement classique, qui va juste servir à indiquer quel est ton numéro de séquence attendu pour que l'autre pair se synchronise. Si l'autre pair n'a pas l'intention de couper la connexion, il ne va pas renvoyer de RST quand il recevra un ACK (qu'il soit bidon ou pas). Mais s'il a effectivement l'intention de couper la connexion, alors le standard TCP classique dit qu'il doit renvoyer le RST, parce que le précédent à potentiellement été perdu.

  • # Pourquoi Nouveau est plus mis en avant que Radeon?

    Posté par . Évalué à  10 . Dernière modification : le 20/02/13 à 10:20

    Hello!

    De ce que j'ai compris, AMD/ATI est beaucoup plus open source-friendly que sont concurrent nVidia. La preuve en est que les spécifications des cartes du premier sont librement accessibles et elles ne le sont pas du tout pour le deuxième. C'est d'ailleurs pour cela que j'ai récemment acheté une Radeon, pour saluer l'implication d'AMD et parce que je pense que c'est la solution la plus pérenne.

    Et pourtant, dans les faits, l'actualité de Nouveau se retrouve toujours plus mise en avant que celle de Radeon. C'est probablement la partie émergée de l'iceberg, il faut avouer qu'il semble y avoir moins de dev pour radeon que pour nouveau, mais je ne comprends pas pourquoi… Surtout quand Linus fait un gros fuck à nVidia, je comprends pas qu'on continue de vouloir mettre en avant leurs cartes plutôt que celles d'AMD.

    Y a-t-il une raison que je ne verrai pas?

    PS: Excellente dépêche, comme toujours… kodos à tous les rédacteurs!

    Merci,
    Creak

    • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

      Posté par . Évalué à  2 .

      je comprends pas qu'on continue de vouloir mettre en avant leurs cartes plutôt que celles d'AMD.

      Question de performances du pilote…

      • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

        Posté par . Évalué à  4 .

        euh sources ? Entre nouveau et radeon, les performances sont à mon avis du côté du dernier des cartes équivalentes…

        Peut-être aussi qu'on parle moins de radeon parce que ça marche ? Je me souviens qu'il y a quelques années les pilotes wifi faisaient parler d'eux… aujourd'hui ça marche et c'es silence radio.

        Le jour où radeon sera bon sur la 3D ou openCL, on risque d'en entendre parler…

        • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

          Posté par . Évalué à  3 .

          Je pensais plutôt au pilote propriétaire Nvidia.
          Il marche bien et offre d'excellentes performances.

          Historiquement, fglrx (pilote propriétaire ATI) était une vraie plaie et tout sauf fiable. Non seulement c'était la galère pour l'installer mais en plus tu avais souvent des crash. Aujourd'hui les choses vont mieux mais il garde sa mauvaise réputation.

          Quand au pilote radeon il est très bon mais en deçà du pilote propriétaire au niveau des performances.

        • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

          Posté par . Évalué à  3 .

          le silence "radio" pour les pilotes wifi, ca explique bien pourquoi on ne voit rien de nouveau sur les pilotes "graphiques"

          pour avoir testé trois fabricants de cartes graphiques, j'ai trouvé que nvidia avec son pilote proprio s'en sort le plus honorablement : les applis opengl sont fluides même dessus le joli compiz, seul problème effectivement : le rendu des couleurs est trop poussé, si je peux me permettre cette mauvaise traduction ça va jusqu'à teindre mon blanc noyau
          j'imagine que c'est aussi une raison du succès de nouveau, cette volonté de rendre libre ces belles perfs que le pilote proprio d'amd ne m'a pas montrées. Par contre je comprends mal pourquoi ces fondeurs de gpu s'associent aussi timidement au libre, sauf intel qui n'a rien à perdre vu la qualité de ses chipsets. Si qq'1 peut m'aiguiller, je suis preneur

    • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

      Posté par . Évalué à  2 .

      Je serais aussi très intéressé par une réponse d'un utilisateur avisé à la question ci-dessus.

      Le but est il de trouver des solutions, ou bien des bonnes questions ?

    • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

      Posté par . Évalué à  2 .

      La preuve en est que les spécifications des cartes du premier sont librement accessibles

      Les spécifications partielles des cartes sont librement accessibles, pour autant que je sache AMD/ATI n'a jamais fourni les spécifications de la partie décodeur vidéo intégré dans ses cartes.
      Et non, refaire la même chose en utilisant la partie graphique, ça n'est pas pareil au niveau utilisation de la batterie pour les ordinateurs portables.

      • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

        Posté par . Évalué à  10 .

        Ca reste toujours infiniment plus que ce que fait nVidia pour le monde libre.
        A un moment il faut aussi soutenir les entreprises qui vont dans ce sens, plutôt que d'investir toutes nos ressources dans le retro-engineering de cartes graphiquesn, tout ça pour un constructeur qui à l'air de se foutre de Linux comme de sa première chaussette.

        • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

          Posté par . Évalué à  10 .

          Ça reste toujours infiniment plus que ce que fait nVidia pour le monde libre.

          Je ne dis pas le contraire.

          tout ça pour un constructeur qui à l'air de se foutre de Linux comme de sa première chaussette.

          Plutôt faux puisqu'ils ont porté leurs pilotes sur Linux, que NVidia en ai rien à faire du libre, ça oui par contre.

        • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

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

          Tout à fait.

          De plus AMD ne fait pas que publier certaines spécifications de ses cartes, mais participe aussi (un peu) au développement des pilotes libres (radeon) et de mesa (http://developer.amd.com/tools/open-source/).

          J'ai un radeon HD 6450 (entrée de gamme), les pilotes libres marchent bien, malgré les faibles performances en 3D comparées aux proprios (mais ça s'améliore doucement au fil du temps).

        • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

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

          C'est pourquoi, quand on n'a pas besoin de performances qui tuent la mort, on prend du Intel tout intégré. Ça juste marche, c'est juste rapide, et c'est développé directement en licence Libre par le constructeur.

          Vu les perfs des pilotes AMD/ATI et l'effort démesuré du constructeur pour améliorer les perfs, faudrait voir si une carte entrée de gamme Radeon avec pilote libre fait vraiment beaucoup mieux que les bons procos Intel. Sinon c'est aussi une solution pour le chauffage l'hiver…

    • [^] # Re: Pourquoi Nouveau est plus mis en avant que Radeon?

      Posté par . Évalué à  10 .

      Parce que les devs de Nouveau communiquent plus que ceux pour AMD?

  • # ordonnancement NUMA

    Posté par . Évalué à  5 .

    Les architectures NUMA, où chaque processeur a un contrôleur
    mémoire dédié, nécessitent une révision de l'ordonnanceur.
    En effet, l'ordonnanceur doit tenir compte de la topologie
    du CPU pour placer un processus sur le cœur le plus proche
    de sa mémoire. L'ordonnanceur actuel est trop naïf pour ces
    architectures, ce qui provoque des pertes de performances.

    Le problème est justement qu'il ne faut que ce soit uniquement l'ordonnanceur qui gère ça. Si les données sont bien réparties en mémoire, il arrivera peut-etre à répartir les processus près de leurs données tout en équilibrant bien la charge parmi les processeurs. Mais dans la plupart des cas, mettre les processus près de leurs données va imposer un déséquilibre de charge de calcul.

    Et on se pose alors la question de migrer certaines données vers un autre noeud NUMA. En gros il faut répartir les données et les calcul en même temps, pas l'un puis l'autre.

    Au final, il faut que l'ordonnanceur et la gestion mémoire se mettent d'accord sur une de ces stratégies :
    1) est-ce qu'on migre les processus près des données (pas très cher, mais peut déséquilibrer la charge de calcul)
    2) est-ce qu'on migre les données près des processus (cher, équilibre mieux la charge de calcul)
    3) ne rien faire, équilibrer la charge et avoir éventuellement des processus qui utilise des données loin d'eux, et donc plus lentement.

    Comparer ces trois approches est très difficile car ça impose de connaître les schémas d'accès mémoire des processus pour évaluer les différents surcoûts ci-dessus.

  • # Système de fichiers pour Flash

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

    Nouveau système de fichiers pour mémoires flash : F2FS

    Le nouveau système de fichiers F2FS (acronyme de Flash-Friendly File-System) qui fait son apparition dans cette version du noyau a été spécialement conçu par Samsung pour les appareils utilisant de la mémoire flash comme les clés USB, cartes mémoires et tous les appareils embarquant ce type de mémoire (tablette, smartphone…).

    Holà, non, je ne crois pas. Il y a deux types de périphériques à mémoire Flash :

    • ceux qui exposent directement la Flash, avec ses petits blocs d'écriture, ses gros blocs d'effacement et ses blocs abîmés par des nombreuses écritures ;
    • ceux qui cachent la Flash derrière une couche d'adaptation (la FTL) qui prend en charge ces détails, et fournissent une interface habituelle par petits blocs de lecture-écriture.

    Ce nouveau système de fichier vise visiblement les premiers.

    Ce n'est pas le premier système de fichiers à avoir cet objectif (citons YAFFS, JFFS2, LogFS ou encore UBIFS) : l'avenir nous dira si le succès est au rendez-vous. Ce nouveau système de fichier cible certaines mémoires flash embarquées et non les disques SSD.

    Voilà : tout comme YAFFS, JFFS2, LogFS et UBIFS, cela viste les mémoires Flash à accès plus ou moins direct, contrairement aux SSD, clefs USB ou cartes SD.

    Les mémoires ciblées contiennent un contrôleur FTL, conçu pour implémenter dans le matériel l'optimisation de mémoire flash que des système de fichiers comme FAT n'ont pas.

    Oulà, oulà, c'est fait pour quel type de périphérique finalement ?

    À noter que Microsoft promeut dorénavant à cet effet exFAT (pour Extended File Allocation Table), un système de fichiers propriétaire et breveté développé en 2006 (au lieu de l'antique FAT32 limité aux fichiers de moins de 4 Go). Ainsi, la norme des cartes mémoire SDXC (qui doivent succéder aux cartes SDHC) prévoit que celles-ci soient formatées par défaut en exFAT. Sous Linux, il existe depuis peu un pilote libre en espace utilisateur (fuse-exfat), sous licence GPLv3, gérant ce système de fichiers.

    FAT, exFAT, ça c'est clairement destiné aux périphériques à accès bloc avec FTL intégrée : les SSD, clefs USB et cartes SD par exemple.

    • [^] # Re: Système de fichiers pour Flash

      Posté par . Évalué à  7 . Dernière modification : le 20/02/13 à 13:42

      Ce nouveau système de fichier vise visiblement les premiers [avec FTL].

      Justement, non. J´ai assisté à la présentation faite par un ingé de Samsung lors de la dernière ELC-E, et f2fs est clairement fait pour les périphériques avec FTL (eg. les SDcards).

      D'ailleurs, on sentait bien derrière ses explications, qu'ils (les dev. f2fs) avaient beaucoup discuté avec leurs collègues hardeux qui concevaient ces SDcards.

      http://elceurope2012.sched.org/event/43d200d4be7a9971f268e521af3dffaf
      http://elinux.org/images/8/81/A_New_File_System_Designed_for_Flash_Storage_in_Mobile.pdf
      http://free-electrons.com/pub/video/2012/elce/elce-2012-hwang-f2fs-filesystem-flash-storage.webm

      Hop,
      Moi.

      • [^] # Re: Système de fichiers pour Flash

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

        On a donc un système de fichiers optimisé pour des contrôleurs d'adaptation de Flash optimisés pour les systèmes de fichiers standard. Bien bien… En tout cas ça vaudrait la peine de l'indiquer clairement je pense.

        • [^] # Re: Système de fichiers pour Flash

          Posté par . Évalué à  8 .

          un système de fichiers optimisé pour des contrôleurs d'adaptation de Flash optimisés pour les systèmes de fichiers standard

          Ouais. Ça fait un peu bizarre à lire, mais c´est exactement ça.

          Alors que, si on avait directement accès à la flash, ou un moyen de charger un firmware alternatif, on pourrait implémenter notre propre algorithme de wear-leveling, voire même utiliser différents algorithme en fonction de l'utilisation.

          En plus, ces firmwares font souvent un travail de sagouin, sont peu optimisés, parfois même peu fiables (parfois au point de rendre inutilisable une flash toute neuve, même après un power-off ! ).

          Mais non. Faut que ça marche sous Windows, le reste on s´en fout.

          Hop,
          Moi.

        • [^] # Re: Système de fichiers pour Flash

          Posté par . Évalué à  6 .

          Ce n’est pas aussi simple car l’objectif de Samsung est de mettre ça dans des appareils mobiles qui utilisent souvent une eMMC. Certaines des ces eMMC sont faites par Samsung, et dans tous les cas, l’ensemble des propriétés des FTL de ces cartes sont connues par Samsung… C’est donc un avantage, car les deux (le FS et le FTL de la carte) s’emboîtent alors très bien. Il y a très peu d’amplification d’écriture par exemple.

          Là où le bas blesse c’est lorsqu’on veut utiliser F2FS sur une carte SD dont on ne connaît pas les propriétés (les tailles de blocs), et ben ça n’est plus du tout efficace. Et rien n’est prévu dans le filesystem pour "découvrir" les paramètres de la SD sous-jacente, il faut le tuner selon les propriété de la carte, ce qui n’est pas un problème pour Samsung, mais un peu plus pour un bidouilleur dans son coin.
          J’ai reprit une partie de ce qui est expliqué ici: http://lwn.net/Articles/518988/

  • # Félicitations

    Posté par . Évalué à  1 .

    That's it, that's all.

    Félicitations pour cette nouvelle news collaborative !

    Allez hop -1 pour futilité, Avec le sourire : )

  • # erreur d'historique?

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

    N'y-a-t-il pas une erreur dans l'historique du noyau? il me semblait (ça remonte loin!) qu'Alan Cox avait effectué le premier portage de Linux, vers m68k, (pas tout à fait officiel peut-être), et que c'était ce travail qui avait rendu le noyau portable.
    J'ai cherché un petit peu, sans retrouver, mais si c'est bien ça, faudrait rendre justice à m'sieur Alan.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: erreur d'historique?

      Posté par . Évalué à  4 .

      Vers l'alpha, je pense, premier port de Linux.

      "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

      • [^] # Re: erreur d'historique?

        Posté par . Évalué à  2 .

        Vers l'alpha […] premier port de Linux.

        A quand un processeur Oméga, pour enfin dire que Linux, c´est l´Alpha et l´Oméga ?

        Hop,
        Moi ---> [].

  • # C'est de la bombe

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

    J'ai installé et configuré le kernel 3.8, il marche très bien et même mieux que le précédent. Je trouve que c'est plus rapide, mais là où j'ai senti une grosse différence c'est avec les yeux Steam qui sont généralement plus fluide !

  • # i386

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

    Mon premier ordinateur…

    Adios, amigos.

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # Vraiment plus performant et plus stable

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

    Du moins chez moi. Le kernel 3.7.9 n'était pas très stable avec l'ahci activé dans le bios. J'avais sans cesse des kernel panic et des erreurs sata3 mais depuis que je suis passé au kernel 3.8, c'est parfait. Aucun kernel panic de la journée ! J'ai trouvé les jeux sur Steam, plus fluide, un gain de quelques FPS et un chargement plus rapide.

    Vraiment c'est du bon travail !

  • # monde professionnel

    Posté par . Évalué à  2 .

    la 2.2 sort un an plus tard, en janvier 1999, avec la prise en charge des m68k et PowerPC, puis, en fin d'année (avec la 2.2.13), des IBM mainframe, ouvrant Linux au monde professionnel ;

    C'est un lancé de troll ou bien sans mainframe pas de professionnels ?
    Cette phrase m'a un peu surprise, mais je dois être le seul puisque personne ne l'a relevé :-)

    • [^] # Re: monde professionnel

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

      C'est sans volonté de troller, je sais plus où j'ai piqué ça c'est pas mon domaine de compétence..!

    • [^] # Re: monde professionnel

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

      Je ne dirais pas que j'ai les réponses, mais je peux faire des suppositions:
      Avec un Linux un peu jeune, les portages auraient pu passer pour des bidouillages de geeks passionnés. Les processeurs m68k et même PowerPC étaient déjà accessibles au grand public.

      En passant aux mainframes IBM, Linux a gagné ses lettres de noblesse (support IBM? intérêt de clients clés?). C'était peut-être un élément déclencheur de l'essor de Linux dans le monde professionnel comme solutions viable?

  • # Le noyau casse la WIFI sur certains ordinateurs portables

    Posté par (page perso) . Évalué à  -1 . Dernière modification : le 05/03/13 à 18:10

    Les versions 3.8.1 et 3.8.2 casse la WIFI.

    J'ai une distribution Debian wheezy/sid, et dispose d'un ordinateur portable ASUS K73S.

    Ce problème a été aussi évoqué sur cette page.

  • # lguest introuvable

    Posté par . Évalué à  0 . Dernière modification : le 10/04/13 à 11:41

    Bonjour,

    Avez vous réussi à recompiler le noyau 3.8 ?

    En effet, que je tente de recompiler le noyau 3.8 ou 3.*, j'ai une erreur de compilation car il lui est impossible de trouver la Documentation lguest.

    Savez vous où je peux l'a trouver ?

    Après une recherche, il y aucune référence à lguest dans le dossier Documentation du tar.

    Du coup, il m'est impossible de le recompiler. J'ai aussi tenté de récupérer la documentation lguest du 3.0 puis l'a placer dans le dossier Documentations du 3.8 mais ça ne fonctionne pas mieux.

    Merci bien pour votre aide

    • [^] # Re: lguest introuvable

      Posté par . Évalué à  0 .

      Tracelog
      make[1]: quittant le répertoire « /usr/src/linux-3.8.6 »
      /usr/bin/make EXTRAVERSION=-20130509 ARCH=i386 \
      -C Documentation/lguest
      make: *** Documentation/lguest: Aucun fichier ou dossier de ce type. Arrêt.
      make: *** [debian/stamp/build/kernel] Erreur 2

Suivre le flux des commentaires

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