Journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64

Posté par . Licence CC by-sa
39
8
sept.
2011

Lors de la sortie de la version 64 bits des x86 faite par AMD, il y avait eu des tas de benchmarks pour étudier les performances entre le mode 32 bits et le mode 64 bits du CPU, avec des résultats variés: gain pour certaines applications (jusqu'à 20%!!) grâce au nombre supérieur de registres visibles par le compilateur, au calcul 64 bits natif, aux appels système rapide mais perte aussi pour d'autres applications principalement a cause de la taille supérieure des pointeurs (ce qui occupe plus de bande passante mémoire et réduit l'efficacité des caches mémoire).
Notons aussi qu'à l'époque certaines applications avaient de l'assembleur codé manuellement pour le mode 32 bit mais pas pour le mode 64 bit, ce qui réduit les performances de manière "artificielle" dans un comparatif..

Pour essayer d'optimiser les performances, le nombre d'application ayant besoin de plus de 4 GO de RAM étant faible, des développeurs Linux proposent une nouvelle ABI nommée x32 permettant d'utiliser des pointeurs 32 bits tout en gardant le CPU en mode 64 bits ce qui permet de maximiser les performances des applications (nombre supérieur de registre visible, calcul 64 bits natif, appel système rapide ET pointeurs 32 bits).
Cette ABI nécessite bien sûr le support du noyau Linux et de GCC, le support GCC n'étant pas encore finalisé, on ne peut pas vraiment faire de mesure de l'amélioration des performances à l'heure actuelle.

Et une question se pose alors: quelle taille utiliser pour time_t dans cette nouvelle ABI?
Si on veut la compatibilité maximale avec les applications 32 bit actuelle, il serait logique de laisser time_t en mode 32 bit cependant Linus s'y est opposé de manière catégorique à cause du bug de l'an 2038.

L'article sur LWN rendre beaucoup plus en détail sur l'implémentation de cette nouvelle ABI sur Linux, à votre avis vas-t'il y avoir une migration vers x32 dans le futur?
Affaire à suivre!

  • # C'est quoi une ABI ?

    Posté par . Évalué à  5 .

    Si c'est ABI je comprend juste un peu.
    Si c'est autre chose, je comprend rien.

    • [^] # Re: C'est quoi une ABI ?

      Posté par . Évalué à  7 .

      Tu as raison j'aurais du clarifier, mais tu as bien trouvé ABI==Application Binary Interface.

  • # 0xc0000000

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

    le nombre d'application ayant besoin de plus de 4 GO de RAM étant faible

    En fait, l'espace d'adressage pour un processus est limité à 3Go sur 32-bit.
    A partir de PAGE_OFFSET (0xc0000000), c'est mappé par le noyau (en fait à cause des différentes zones tas/mmap/stack ça peut être moins, par exemple le tas était longtemps limité à environ 1Go). Et ça peut filer vite, par exemple dans un programme multi-thread (taille réservée pour la stack de chaque thread), ou en Java :-)

    • [^] # Re: 0xc0000000

      Posté par . Évalué à  5 .

      En fait, l'espace d'adressage pour un processus est limité à 3Go sur 32-bit.

      En mode x86 normal oui, dans les commentaires de l'article sur LWN il est marqué qu'il y a 4 Go avec x32, j'ignore si c'est correcte mais ça me parait possible: le noyau est en mode 64-bit lui..

      • [^] # Re: 0xc0000000

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

        Oui je pense que c'est ça, le kernel a déjà de la place pour lui dans l'espace 64-bits, donc les applications peuvent utiliser la totalité des 32-bits des adresses pour elles toutes seules.

    • [^] # Re: 0xc0000000

      Posté par . Évalué à  3 .

      Pas tout à fait vrai: avec les extensions PAE (et le noyau adéquat), il est possible d'avoir des processus qui utilisent plus de 3Go, même sur des plateformes x86 comme mentionné sur la page wikipedia

      • [^] # Re: 0xc0000000

        Posté par . Évalué à  3 .

        Non, PAE permet d'utiliser des adresses physiques sur 36 bits. Les adresses virtuelles sont toujours limitées à 32 bits, ce qui fait que l'espace adressable maximum pour un processus ne dépasse pas les 4 Go, PAE ou pas PAE.

        • [^] # Re: 0xc0000000

          Posté par . Évalué à  -3 .

          relis son poste. Tu peux adresser plus de 3 (pas 4) Go en 32-bit avec un noyau PAE.

          • [^] # Re: 0xc0000000

            Posté par . Évalué à  6 .

            C'est toi qui ne comprend pas. L'espace d'adressage virtuel d'un processus n'a rien à voir avec l'utilisation ou non du PAE. La page Wikipedia parle de mémoire physique, en aucun cas de mémoire virtuelle. Avec un noyau en PAE, on a beau pouvoir adresser jusqu'à 64 Go (36-bits) au niveau physique, ça ne change strictement rien pour les processus.

      • [^] # Re: 0xc0000000

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

        En mode x86 normal oui, dans les commentaires de l'article sur LWN il est marqué qu'il
        y a 4 Go avec x32

        Je faisais allusion au mode 32-bit "standard". Avec x32, je n'ai pas regardé en détail mais il est probablement possible de mapper jusqu'à 4Go en usermode.

        Pas tout à fait vrai: avec les extensions PAE [...] il est possible d'avoir des processus qui utilisent plus de 3Go

        Non.
        PAE permet d'exploiter jusqu'à 64Go de mémoire au total, mais un processus donné ne peut pas adresser plus de 4Go (en fait 3Go):

        x86 processor hardware-architecture is augmented with additional address lines used to select the additional memory, so physical address size increases from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB. The 32-bit size of the virtual address is not changed, so regular application software continues to use instructions with 32-bit addresses and (in a flat memory model) is limited to 4 gigabytes of virtual address space. The operating system uses page tables to map this 4-GB address space into the 64 GB of physical memory. The mapping is typically applied differently for each process. In this way, the extra memory is useful even though no single regular application can access it all simultaneously.

        Pour Linux, il existe un patch dit 4/4 qui permet de mapper 4Go en usermode, mais au détriment des performances (tu dois invalider le TLB et changer la table des pages à chaque changement de contexte usermode/kernel).
        Mais tout ça reste un hack, la vrai solution c'est le passage à 64-bit...

        • [^] # Re: 0xc0000000

          Posté par . Évalué à  2 .

          galactikboulay et toi interprétez mal le post de Laurent Go: il dit que la limitation a 3Go n'existe pas avec PAE ce qui est vrai, il n'a pas parlé de celle de 4Go..

          • [^] # Re: 0xc0000000

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

            il dit que la limitation a 3Go n'existe pas avec PAE ce qui est vrai

            Non, c'est faux.
            http://www.redhat.com/archives/rhelv5-list/2008-November/msg00097.html
            http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-kernel.html

            C'est pour ça qu'on a inventé le split 4G/4G (RHEL appelle ça kernel-hugemem).
            Tu peux faire le test...

            • [^] # Re: 0xc0000000

              Posté par . Évalué à  0 .

              tu parles du kernel-PAE lorsque d'autres parlent d'une caractéristique d'un processeur x86. Ton kernel-hugemem utilise le support PAE du processeur non?

              • [^] # Re: 0xc0000000

                Posté par . Évalué à  4 .

                Non il a raison. Le patch 4/4 n'a pas besoin de PAE. La ruse c'est de garder uniquement 16MB dans l'espace d'adressage du processus pour le noyau et de flusher le TLB quand tu passes en code système. Sur un noyau classique au dessus de PAGE_OFFSET tu as tout ce qu'il faut (même mapping pour tout les processus). Du coup le patch est très couteux pour les processus qui font beaucoup d'aller retour entre code utilisateur et noyau. Après 4/4 est souvent couplé à PAE par ce qu'il est généralement utilisé sur les systèmes avec plus de 4G de RAM. Mais on pourrait très bien avoir 4G de RAM et vouloir donner cet 4G à un unique processus et donc justifié un noyau 4/4 sans PAE.

                Je crois que j'avais écrit une petite doc sur le fonctionnement de tout les patchs de cette époque là (vers 2004). Faudrait que je cherche si ca intéresse quelqu'un. Autrement tout doit toujours être dispo dans les archives de kerneltrap.

      • [^] # Re: 0xc0000000

        Posté par . Évalué à  0 .

        Arf, les joies des commentaires trop laconiques...

        Donc, dans ma phrase, je mentionne deux choses (séparées par et, ce qui implique la présence des deux):
        - un kernel adéquat: c'est le fameux kernel 4G/4G mentionné par neologix
        - les extensions PAE: pas nécessaires en théorie, mais dans la pratique si car utiliser 4Go pour un processus n'a d'intérêt que si la machine possède plus de 4Go de mémoire et que le noyau est capable de l'utiliser.

        Exemple: il y a quelques années au boulot, on ne disposait pas de machines 64bits mais uniquement 32bits avec 8Go, et aussi de grosses bases de données pour lesquelles un 1Go en plus faisait une énorme différence, donc utilisation du noyau spécial (quant à la présence des extensions PAE, celles-ci remontent au Pentium pro, une éternité presque...)

        Désolé pour la confusion, la prochaine fois, je serai plus précis.

        (Et je rassure tout le monde, on est très vite passé au 64bits et à des processus utilisant plus de 4Go)

  • # J'approuve

    Posté par . Évalué à  10 .

    Si on veut la compatibilité maximale avec les applications 32 bit actuelle, il serait logique de laisser time_t en mode 32 bit cependant Linus s'y est opposé de manière catégorique à cause du bug de l'an 2038.

    On est jamais trop prudent ! Dans les années 80 on a codé sur deux chiffres (BCD) les années, et lors du passage à l'an 2000, il a fallu revoir le code; certains se contentant d'un if ( x < ??? ) then ... les ??? pouvant êtres 20, 30, 40, 50, ??? 58 ???, 60... laissant le soin au futur mainteneur de gérer le cas lorsqu'il se reproduirai.

    Loin de moi l'idée de retirer du travail aux futures génération (où à moi même), mais si on peut éviter ce bug à la con, c'est bien. Surtout que le bug de l'an 2000, il est facile à expliquer; celui de 2038 est plus ardu pour un non informaticien.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: J'approuve

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

      Si on utilise un nombre non-signé pour représenter le nombre de secondes depuis le 1er janvier 1970, on tiendrait jusqu'en 2106, ce qui est déjà beaucoup mieux.

      Le bug de l'an 2038, c'est pcq c'est un nombre signé qui est utilisé, et donc en théorie, avec ce système, on peut dire qu'un fichier date de 1902. Ou mieux, envoyer un mail datant de 1902, ce qui serait assez rigolo (mais je n'ai pas été lire la RFC pour voir si c'était possible, et si ça tombe le mail se base sur une autre unité).

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: J'approuve

        Posté par . Évalué à  9 .

        En parlant de date, un truc rigolo c'est excel et les dates. Je vous fais un copie-coller d'un mail envoyé à des collègues qui ne comprenaient plus rien.

        Pour Exel, la date initiale est le
        00/01/1900 (c'est bien 00, ce n'est pas une faute de frappe) et pour Mac c'est
        le 01/01/1904 sous le même logiciel (Excel). Bref, c'est une belle connerie
        et le plus drôle, c'est la raison de ce décalage. Les (ingénieurs)
        stagiaires de chez windows ont compté 29 jours pour le mois de février 1900
        sous windows et ne voulais pas faire la même erreur sous mac …

        Mais bon, pour faire encore plus simple, sous Acces (produit microsoft de la
        même suite qu'Excel), les dates sont comptées à partir du 30/12/1899 !!!!
        Pourquoi pas 31 ? Et bien, comme ça le 1er mars 1900 est codé de la même
        façon sous les deux calendriers (1900 et 1899) mais dans le premier
        calendrier il existe un 29 février et pas dans le deuxième. Je ne vous dis
        pas le bordel quand il faut compter le nombre de jours entre deux dates…

      • [^] # Re: J'approuve

        Posté par . Évalué à  2 .

        Le mail (tant SMTP que IMAP) se repose sur une représentation textuelle des dates, donc tu pourrais même théoriquement envoyer un e-mail daté de l'an 1, de l'ère préhistorique ou du cinquième millénaire sans émouvoir le protocole.

        Après la question c'est plutôt de savoir comment les différents programmes en présence vont réagir à une date non représentable par un timestamp. Tout dépend de s'ils se préoccupent de la date en question et de la façon dont ils vont la représenter en interne.

        • [^] # Re: J'approuve

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

          Comment tu représentes une date avant l'an 0 dans un e-mail ?

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

          • [^] # Re: J'approuve

            Posté par . Évalué à  2 .

            Effectivement, pour la RFC 2822 une année doit compter 4 chiffres et être supérieure à 1900. Donc on a droit aux dates comprises entre 1970 et 9999. Mon côté marseillais a peut-être pris le dessus.

            Ceci n'enlève cependant rien à l'argument, vu qu'un timestamp non signé n'est pas capable de représenter une date avant 1970, alors que le format le permet.

  • # ABI Gaël

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

    C'est moi où l'ABI de Linux change tout le temps ?

    • [^] # Re: ABI Gaël

      Posté par . Évalué à  10 .

      C'est moi où l'ABI de Linux change tout le temps ?

      Oui, elle change tout le temps. Mais uniquement par ajouts. Donc, pour un programme écrit à un instant t₀, le noyau lui garantit que l'ABI sera toujours compatible à t₁>t₀, au point que même un bug présent dans cette ABI sera toujours présent. C'est la grosse problématique de l'ABI du noyau : une fois publiée, elle sera maintenue ad-libitum.

      Cependant, là, il faut plutôt voir ça comme une nouvelle ABI. C'est à dire, un nouvel ensemble de syscall, un nouveau format de passage des paramètres dans les registres, etc... C'est un (tout petit) peu comme si on inventait un nouveau processeur, et qu'il fallait définir son ABI.

      Hop,
      Moi.

      • [^] # Re: ABI Gaël

        Posté par . Évalué à  -8 .

        Oui, elle change tout le temps. Mais uniquement par ajouts. Donc, pour un programme écrit à un instant t₀, le noyau lui garantit que l'ABI sera toujours compatible à t₁>t₀, au point que même un bug présent dans cette ABI sera toujours présent. C'est la grosse problématique de l'ABI du noyau : une fois publiée, elle sera maintenue ad-libitum.

        C'est d'ailleurs pour celà que les modules compilés avec une version du noyau fonctionne parfaitement avec toutes les versions suivantes, que les fabriquant de cartes graphiques n'ont jamais besoin de te faire sous compiler des wrappers à la con pour leur pilote proprios, que les progs codés à l'époque de l'alsa 0.8 font des sons absolument parfait encore aujourd'hui et que les ni les appels systèmes de sécurité (genre SE-Linux) ni les appels pilotes génériques (genre WLan) n'ont besoin d'être intégralement réécrits tous les deux mois.

        Tu as fumé quoi au juste ?

        Une ABI Linux tu es content (mais alors vraiment content) quand elle tient deux mois, même les ABI d'abstractions (genre IDE, SATA,WLan, AGP etc.) elles défilent plus vites que les étoiles filantes un soir d’août.
        Déjà que les API tiennent pas 6 mois pour la plupart, alors les ABI tu penses.

        Alors je t'accorde le bénéfice du doute, tu as confondu API (le code reste compatible, mais il faut recompiler), avec ABI (les binaires restent compatibles). Mais ceci étant, même au niveau API c'est une véritable valse. A part les API Posix qu'on ne peut que difficilement changer (et encore certaines interprétations par le noyau Linux laissent songeur), les API Linux pur ont tendance à avoir une sacrée bougeotte (à part OSS, qui est l'API la plus stable qui soit bien qu'elle entre dans sa sixième année de deprecation)

        • [^] # Re: ABI Gaël

          Posté par . Évalué à  10 .

          Vous ne parlez pas de la même ABI.

          Il n'y a pas de stabilité de l'ABI interne de Linux.

          L'ABI dont on parle ici est l'ABI kernel user. Ça aurait du être évident vu le contexte.

          • [^] # Re: ABI Gaël

            Posté par . Évalué à  2 .

            L'ABI dont on parle ici est l'ABI kernel user.

            Tu veut dire comme l'APM, l'ACPI, Alsa, OSS, MTTR, DRM/DRI, V4L2, SELinux etc.

            Il y a combien de trucs qui n'ont pas grand chose à voir avec le fonctionnement interne du kernel, mais que tu peux pas vraiment compiler si tu n'as pas les sources à jour du kernel ?

            L'ABI dont on parle ici est l'ABI kernel user. Ça aurait du être évident vu le contexte.

            Ca l'était. Je peux comprendre qu'on me reproche d'avoir parlé des modules, même si je ne parlais que des modules qui se pluguent sur une interface générique (là aussi ca aurait du être évident); mais pour le reste...
            Même fsck a du mal à suivre les évolutions VFS/Ext4 sans une recompilation régulière.

            • [^] # Re: ABI Gaël

              Posté par . Évalué à  -1 .

              L'ABI dont on parle ici est l'ABI kernel user.

              Tu veut dire comme l'APM, l'ACPI, Alsa, OSS, MTTR, DRM/DRI, V4L2, SELinux etc.

              Il y a combien de trucs qui n'ont pas grand chose à voir avec le fonctionnement interne du kernel, mais que tu peux pas vraiment compiler si tu n'as pas les sources à jour du kernel ?

              Je suis entièrement d'accord avec vous, pour utiliser OSS, il faut appeler des fonctions qui changent absolument tout le temps, comme par exemple open(2), write(2) et autres choses rarissimes.

              • [^] # Re: ABI Gaël

                Posté par . Évalué à  -1 .

                Je suis entièrement d'accord avec vous, pour utiliser OSS,

                Cf mon post (moinsé)plus haut.

                (à part OSS, qui est l'API la plus stable qui soit bien qu'elle entre dans sa sixième année de deprecation)

                Pour info, la personne me dit que je me trompe de type d'ABI alors que mon post antérieur parlait bien des bonnes ABI.

            • [^] # Re: ABI Gaël

              Posté par . Évalué à  5 .

              Même fsck a du mal à suivre les évolutions VFS/Ext4 sans une recompilation régulière.

              Dommage, on aurait pu croire que tu t'y connaissais…
              Mais comme fsck utilise grosso modo rien du code du noyau (sauf cas spécifiques), et en particulier n'a rien à voir avec le VFS…

              • [^] # Re: ABI Gaël

                Posté par . Évalué à  -1 .

                Mais comme fsck utilise grosso modo rien du code du noyau (sauf cas spécifiques)

                Un truc super ultra rare, comme un partitionnement EFI ?

                en particulier n'a rien à voir avec le VFS…

                C'est clair que de bosser sur des devices virtuels sans aucune geométrie ca n'influe pas vraiment sur fsck. Et puis corriger un superblock VFS ou remapper les inodes, ca n'a rien à voir avec le boulot de fsck non plus..

                • [^] # Re: ABI Gaël

                  Posté par . Évalué à  1 .

                  Et puis corriger un superblock VFS ou remapper les inodes, ca n'a rien à voir avec le boulot de fsck non plus..

                  Hum, il dit qu'il voit pas le rapport ?

                  Déjà tu expliqueras ce qu'est un «superblock VFS», qu'on rigole…
                  Et puis comme tu l'as dit, c'est le boulot de fsck, donc le noyau s'en tamponne le coquillard avec une babouche. fsck prend le FS sans utiliser le module noyau requis, pour justement réparer et rendre à nouveau le FS utilisable…

                  • [^] # Re: ABI Gaël

                    Posté par . Évalué à  0 .

                    Déjà tu expliqueras ce qu'est un «superblock VFS», qu'on rigole…

                    Tout système de fichier monté en VFS (ie tout système de fichier ou presque de nos jours) se voit attribuer un superblock VFS, qui contient entre autre le nom du device correspondant, les pointeurs inodes, la taille des blocks, les pointeurs vers les fonctions du FS, le type de fichier et les pointeurs vers les spécifiques du FS.

                    fsck prend le FS sans utiliser le module noyau requis, pour justement réparer et rendre à nouveau le FS utilisable…

                    Il ne va pas utiliser les fonctions du FS, mais il va quand même devoir se taper une petite tranche de causette avec la couche VFS pour savoir ce quel est le FS sous-jacent. Il accède pas vraiment aux devices en raw non plus.

                    • [^] # Re: ABI Gaël

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

                      Il ne va pas utiliser les fonctions du FS, mais il va quand même devoir se taper une petite tranche de causette avec la couche VFS pour savoir ce quel est le FS sous-jacent. Il accède pas vraiment aux devices en raw non plus.

                      Mais fsck doit être lancé sur un système de fichier non-monté (ext2/3/4, voir man 8 e2fsck, XFS voir man 8 xfs_repair, ...), je vois pas ce que la couche VFS vient faire là-dedans ?

                      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                      • [^] # Re: ABI Gaël

                        Posté par . Évalué à  -4 .

                        Mais fsck doit être lancé sur un système de fichier non-monté

                        Sauf si du RAID soft s'en mêle. Auquel cas un certains nombres d'opérations doivent être faite en mono-utilisateur avec les systèmes montés en read-only. Notamment quand on change la taille des disques RAID ou que l'on étend une grappe à un nouveau disque.
                        Dans ce cas là VFS sert pas mal, notamment si il y a un superblock persistant RAID à mettre en place ou à corriger.

                        • [^] # Re: ABI Gaël

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

                          De nouveau, le RAID logiciel est dans une couche inférieure au système de fichier et le contrôle du système de fichier se fait toujours avec le système de fichier non-monté (sauf système de fichier prévu pour le contrôle à chaud (comme OCFS2, mais c'est uniquement pour empêcher les autres nœuds d'accéder au système de fichier durant le contrôle)).
                          Ensuite l'agrandissement c'est un cas particulier, comme la défragmentation d'ailleurs, qui va dépendre du système de fichier. Mais, normalement, les systèmes ext3/4 et XFS peuvent être redimensionné à chaud, donc interaction avec le noyau ... mais bon on parlait de fsck et lui fonctionne sans intervention du noyau.

                          Et le RAID logiciel de Linux, pratiquement toutes les opérations peuvent être faite à chaud en continuant à utiliser le système de fichier, monter ou démonter le système de fichier, ajouter ou supprimer un disque du RAID, voir modifier le type de RAID. Il n'est même pas nécessaire d'avoir un RAID fonctionnel pour faire un fsck ...

                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                          • [^] # Re: ABI Gaël

                            Posté par . Évalué à  -5 .

                            le RAID logiciel est dans une couche inférieure au système de fichier et le contrôle du système de fichier se fait toujours avec le système de fichier non-monté

                            Premièrement le système RAID est un FS (un genre de) lui-même et il utilise un certain nombre de mécanismes VFS lui même. Deuxièmement en single user il est possible de faire un check d'un système de fichier si il est monté en R/O et c'était bien pratique (jusqu'en 2008/2009) pour la récupération d'infos sur un RAID primaire boot. A ma connaissance ca existe toujours (je n'utilise quasiment plus Linux depuis 18 mois, mais ca m'étonnerai franchement que ca ait disparu)

                            mais bon on parlait de fsck et lui fonctionne sans intervention du noyau.

                            Je rappelle ce que j'ai dit, à savoir que fsck a du mal à suivre toute les variations du noyau, principalement avec les modifs ext4 et VFS.
                            Déjà fsck peut fonctionner sans intervention du noyau, mais généralement il utilise quand même pas mal les interface que lui fourni le noyau.

                            Typiquement sur une partition RAID soft, fsck doit pouvoir faire la différence entre les cas suivant (entre autres):

                            • pilote RAID chargé, device raid construit, superblock RAID généré par le noyau
                            • superblock RAID persistant, device raid construit, pilote RAID chargé
                            • superblock RAID persistant, device raid construit, pilote RAID non chargé

                            Sinon il ne peut que faire des conneries, et généralement ca fini par un superblock corrompu au reboot.

                            Après fsck a été modifié plusieurs fois au cours des dernières années pour prendre en compte tout un tas d'évolutions, par exemple les devices sans géométrie, les variations de superblock persistant, les modifications d'ext4 (avec un grosse flopée de bugs fin 2009 début 2010 notamment sur les OS 64bits).

                            A aujourd'hui je n'utiliserais pas un fsck de 2009 pour checker une bête partition ext2 des familles sur un kernel 2.6.30 ou plus. En théorie ca devrait marcher, en pratique des fois il y a des surprises. Et si la partition est un poil exotique (par exemple du RAID ou du chiffrement par dessus) je déconseille vraiment.

                            • [^] # Re: ABI Gaël

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

                              Premièrement le système RAID est un FS (un genre de) lui-même et il utilise un certain nombre de mécanismes VFS lui même.

                              Le RAID logiciel travail en terme de bloque de données, pour lui un fichier, un répertoire, les droits et autres attributs étendus n'existent pas, la swap peut être sur un RAID. VFS, Virtual File System, représente l'arborescence des fichiers et répertoires (et autres) dans le noyau, c'est simplement une couche d'abstraction où vont se greffer les différents systèmes de fichiers selon leur point de montage; ce qui permet au noyau de travailler de manière identique avec XFS et ext3 par exemple.
                              Le système de fichier s'occupe de gérer la structure que les données auront sur le disque (ou autre média).
                              Pour le contrôle en lecture seul, c'est évidemment possible de le faire et même monté en écriture, c'est juste déconseillé car fsck va modifier la structure sur le disque et la couche VFS ne sera pas au courant de ces modifications. Alors oui, quand tu fais ton contrôle au démarrage du système de fichier monté en lecture seul ça va fonctionner car ton système de fichier va être remonté en lecture-écriture un peu plus tard.

                              Typiquement sur une partition RAID soft, fsck doit pouvoir faire la différence entre les cas suivant (entre autres):

                              fsck se soucie du RAID autant que moi des morpions du pape. fsck contrôle que la structure, sur un média donné, d'un système de fichier, corresponde à ce qui est attendu. Après il évident qu'il faut avoir accès à la partition où se trouve le système de fichier pour lancer fsck. Mais fsck ne sait même pas que le RAID existe, que le système est chiffré ou qu'il s'agisse d'un fichier d'image de disque.

                              A aujourd'hui je n'utiliserais pas un fsck de 2009 pour checker une bête partition ext2 des familles sur un kernel 2.6.30 ou plus. En théorie ca devrait marcher, en pratique des fois il y a des surprises. Et si la partition est un poil exotique (par exemple du RAID ou du chiffrement par dessus) je déconseille vraiment.

                              Tu contrôles le système de fichier à la main ? Bon si tu t'obstines à faire des contrôles sur des partitions montées, je comprend que tu aies des surprises, mais sinon ça fonctionne. Regarde ce que dis la page de manuel de e2fsck :

                              Veuillez noter qu'en général, il n'est pas sûr d'exécuter e2fsck sur des systèmes montés. La seule exception est quand l'option -n est spécifiée, et que les options -c, -l ou -L ne sont pas spécifiées. Cependant, même si la commande est sûre, les résultats affichés par e2fsck peuvent ne pas être valable
                              si le système de fichiers est monté. Si e2fsck vous demande si vous souhaitez ou non vérifier un système de fichiers monté, la réponse correcte est « no » (non). Seuls les experts qui savent vraiment ce qu'ils font devraient pouvoir considérer répondre autrement à cette question.

                              En gros elle dit que tu dois arrêter de faire des fsck sur des partitions montées.

                              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                              • [^] # Re: ABI Gaël

                                Posté par . Évalué à  -3 .

                                Premièrement le système RAID est un FS (un genre de) lui-même et il utilise un certain nombre de mécanismes VFS lui même.
                                Le RAID logiciel travail en terme de bloque de données, pour lui un fichier, un répertoire, les droits et autres attributs étendus n'existent pas

                                Tout à fait, c'est pour cela que j'ai dit "un certain nombre de mécanismes". Par exemple, le superblock et les blocksizes.

                                ce qui permet au noyau de travailler de manière identique avec XFS et ext3 par exemple.

                                J'imagine que tu voulais dire "Ce qui permet au noyau de présenter les mêmes interfaces pour XFS et ext3"

                                fsck se soucie du RAID autant que moi des morpions du pape.
                                fsck contrôle que la structure, sur un média donné

                                Oui, alors le média il a pas de géométrie, il est monté - éventuellement en mode forcé sans les pilotes - dans une zone non standard et en plus il possède deux superblocks à la queueleuleu. Et pour finir le blocksize réel est indépendant du blocksize hardware ou du blocksize détecté dans le premier superblock.
                                Je te jure que ca nécessite un peu de code spécifique pour gérer ça.

                                En gros elle dit que tu dois arrêter de faire des fsck sur des partitions montées.

                                Sauf si je suis sur de savoir ce que je fais. Vu le nombre de moins que je prend je dois être un rigolo, mais vu le nombre de RAID-5 cassés que j'ai récupéré sur des Linux, je dois être un rigolo avec beaucoup de chance.

                • [^] # Re: ABI Gaël

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

                  Un truc super ultra rare, comme un partitionnement EFI ?

                  Tu veux sans doute parler d'une GUID Partition Table, plutôt ? Ce n'est pas rare du tout.

      • [^] # Re: ABI Gaël

        Posté par . Évalué à  5 .

        C'est une vision partielle des choses. Certaines vielles ABI moisies sont graduellement dépréciées et supprimées de Linux ou modifiées pour quelque chose de meilleur. Les syscall restent là, et évidemment les passages de params sont gravés dans le marbre une fois pour toute au début, mais ce qu'il y a dans /proc ou /sys ou /dev (etc) fait aussi partie de l'ABI et peut doucement bouger, même si la règle est effectivement de garder de la retrocompatibilité à moyen/long terme même pour tout ça.

        • [^] # Re: ABI Gaël

          Posté par . Évalué à  8 .

          On parle d'API noyau et utilisateur.

          L'ABI, définit seulement la manière de gérer les appels de fonctions C : dans quel registres sont les arguments, qui sauve les registres temporraires entre l'empelant et l'appeler (callee-save vs caller-save), comment est gérer la pile, comment les types C sont traduit en registre (promotion des char en int par exemple).

          Bref, rien à voir avec les appels systèmes.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: ABI Gaël

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

            L'ABI du noyaux ce sont les appels systèmes. (c.-à.-d. l'interface entre le mode utilisateur et le mode noyaux)

            La manière de gérer les appels de fonctions et l'utilisation des registres est plutôt dictée par L'ABI du langage ou du compilateur

          • [^] # Re: ABI Gaël

            Posté par . Évalué à  2 .

            ABI est un terme générique que l'on emploie dès que l'on parle d'un sujet qui a un impact sur une compatibilité binaire. Quelques soient les binaires en question. Savoir précisément de quoi on parle quand on dit "ABI" nécessite donc de prendre en compte le contexte. Pour avoir lu tout le thread d'origine, je suis à 200% certain que l'ABI dont il est question ici est l'interface kernel user, avant tout les syscalls, mais il a été aussi évoqué des adaptations dans /sys dépendant de l'architecture, donc l'ABI dont on parle est bien celle complète de la définition classiquement utilisée par les kernel hackers parlant d'interface kernel user.

  • # ...

    Posté par . Évalué à  2 .

    Pour essayer d'optimiser les performances, le nombre d'application ayant besoin de plus de 4 GO de RAM étant faible,

    C'est pas tout a fait vrai pour la memoire virtuel avec le prelink (qui essaye de charger chaque bibliothèque a des adresses différentes)

  • # compatibilité avec le X64 ?

    Posté par . Évalué à  1 .

    J'espère qu'ils vont pouvoir faire une compatibilité avec le X64 pour pouvoir utiliser tout de même des lib 64 bits et éviter les duplications.

    "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

    • [^] # Re: compatibilité avec le X64 ?

      Posté par . Évalué à  4 .

      J'ai du mal à voir comment on pourrait garder la compatibilité avec des tailles de pointeur différentes.

      • [^] # Re: compatibilité avec le X64 ?

        Posté par . Évalué à  -1 .

        Il suffit de définir un moyen de passer de l'un à l'autre. Mais c'est vrai que définir 2 type de pointeur de manière implicite risque de produire des effets étranges.

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: compatibilité avec le X64 ?

          Posté par . Évalué à  1 .

          Outre les difficulté techniques que ça représenterait (je suis même pas sûr que ça soit faisable), ça ferait perdre tout son intérêt à ce truc.

          De base, le gain de performance de ce mode bâtard 32/64 bits risque d'être au mieux marginal pour la plupart des applications (par rapport à du vrai 64 bits). Si en plus on ajoute un système de conversion de pointeurs pour appeler du code situé dans des bibliothèques 64 bits (qui ne vont donc pas profiter du gain de performance apporté par les pointeurs 32 bits), il ne restera plus aucun intérêt.

      • [^] # Re: compatibilité avec le X64 ?

        Posté par . Évalué à  4 .

        Avec une technologie magique et révolutionnaire (et brevetée) !

        BeOS le faisait il y a 15 ans !

  • # ABI 32 bits et time_t

    Posté par . Évalué à  3 .

    Je peux parfaitement comprendre qu'un programme compilé sur une archi i686 puisse toujours fonctionner si on rajoute des nouveaux registres, ils seront juste pas utilisés.

    Par contre, si on change la taille du type time_t, on casse l'ABI et un programme compilé pour i686 (avec un time_t de 32 bits) ne pourra pas interragir avec une lib x32 (avec un time_t de 64 bits) et inversement.

    Donc, vous emballez pas les gars, x32 ne sera pas plus compatible avec x86 que x84 ne l'est, et cela ne vous permettra pas d'utiliser tout le potentiel de votre core 2 duo installé du temps où x64 était réservé aux téméraires sans le réinstaller...

    Du coup l'intérêt est relativement limité. Tant qu'à réinstaller, autant réinstaller du x64 directement...

    • [^] # Re: ABI 32 bits et time_t

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

      Pour moi l'interet c'est de l'avoir installé en même temps x86_64 (voire aussi i686 pour la compatibilité avec les vieilles applis 32-bits). L'abi est de toute façon differente de i686, on ne peut pas faire utiliser une lib i686 à une appli x32 , mais les differents systemes peuvent coexister ensembles et ça c'est interessant puisque chaque abi a ses avantages et ses inconvenients

      • [^] # Re: ABI 32 bits et time_t

        Posté par . Évalué à  2 .

        Oui, alors on peut déjà installer des programmes i386 avec un noyau x64. Je ne pense pas que le fait de gagner des clopinettes dans des cas très rares justifie le fait de maintenir une nouvelle infrastructure au sein du noyau et d'installer une troisième copie de tout le système.

        Je peux voir l'intérêt théorique (se faire travailler les méninges sur quelque chose que personne d'autre n'a fait) mais pour qu'une infra se développe, soit maintenue et soit correctement supportée, il faut également qu'elle ait un intérêt pratique évident, ce qui aurait probablement été davantage le cas si l'infra x32 remplaçait "au vol" l'infra x86 en étant compatible avec les anciens programmes.

    • [^] # Re: ABI 32 bits et time_t

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

      Les programmes sont recompilé de manière à utiliser plus de registres, un time_t de 64bit, et plein d'autre trucs de la nouvelle architecture, mais en utilisant des pointeur de 32 bit au lieu de 64 bit.

      Avantage: moins d'utilisation de mémoire (et donc moins de cache-miss)

      En effet, si tu as une structure du genre:

      struct Node {
         Node *left; 
         Node *right;
         Data *payload
      };
      
      

      Chaque node utilise 24 octets si les pointeurs font 64 bits, mais seulement 12 octests avec des pointeurs en 32bits. S'il y a beaucoup de node, tu perds énnormément en mémoire.
      • [^] # Re: ABI 32 bits et time_t

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

        Cependant, d'après mon expérience, en réalité, les pointeurs n'occupent pas tellement de mémoire comparé au reste (pixmaps, images, chaîne de caractères, autres données)
        Je parle ici principalement d'applications desktop. Peut-être que d'autre type d'applications utilisent plus de pointeurs. Les benchmarks nous dirons si ça vaux le coup.

        Mais j'en profite quand même pour citer Donald Knuth

        It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less
        than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only
        waste half the memory, they effectively throw away half of the cache.

        • [^] # Re: ABI 32 bits et time_t

          Posté par . Évalué à  3 .

          C'est tout à fait vrai, cela dit on peut avoir besoin d'un espace mémoire virtuel sur 64-bits sans pour autant avoir besoin de quantités de RAM astronomiques, par exemple lorsqu'on mappe des gros fichiers en mémoire (via mmap()).

      • [^] # Re: ABI 32 bits et time_t

        Posté par . Évalué à  1 .

        Moui, après, les spécifications du matos ont suivi le passage vers les 64 bits, et le lien du journal semble indiquer qu'il n'y a pas vraiment de gain et qu'on met une tonne d'indirections dans tous les sens.

  • # ABI 16 bits?

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

    Et tant qu'à faire, pourquoi pas une ABI 16 bits pour économiser encore plus de mémoire sur les pointeurs?

    Mieux, je propose l'ABI la plus économe du monde : 1 bit. Cherchons maintenant, amis Shadocks, l'utilité d'un pointeur qui ne peut viser que deux adresses.

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

    • [^] # Re: ABI 16 bits?

      Posté par . Évalué à  3 .

      Et tant qu'à faire, pourquoi pas une ABI 16 bits pour économiser encore plus de mémoire sur les pointeurs?

      Il n'y pas tant que ça d'applications qui ont besoin de moins de 64 Mo de mémoire..

      • [^] # Re: ABI 16 bits?

        Posté par . Évalué à  3 .

        64 Ko de mémoire...

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: ABI 16 bits?

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

          J'ai faux si je calcule qu'on adresse 2¹⁶ zones de 2 octets soit 130ko? Mais le processeur 286 pouvait adresser 16Mo de RAM...

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

          • [^] # Re: ABI 16 bits?

            Posté par . Évalué à  4 .

            D'après la doc, le 286 n'a pas un bus d'adresse de 16 bits mais de 24 bits et de la segmentation.

      • [^] # Re: ABI 16 bits?

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

        Ben tout le foisonnement de petits outils unix, non? Et puis aussi les services, etc.

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

        • [^] # Re: ABI 16 bits?

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

          Pour les petits outils, ça veut dire limiter la taille de fichier qu'on leur donne, ça risque d'être souvent limité. Pour les services, il doit pas y en avoir beaucoup en dessous de 130ko.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: ABI 16 bits?

      Posté par . Évalué à  3 .

      Remarque, les buffers overflow seront plus simples à éviter.

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

  • # Idée trés bonne

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

    Personnellement je trouve l'idée très bonne.

    J'ai une machine 64-bit mais j'ai ré-installé un linux 32-bit (et je perd donc l'intérêt du 64-bit) car je n'ai que 2Go de RAM et qu'en 32-bit j'ai deux fois plus de RAM libre qu'en 64 bit (ou je me retrouve avec une mémoire pleine et un PC qui swap).

    Pourtant j'utilise des outils Desktop :
    - KDE 4 (KMail, ...)
    - Kdevelop pour le développement.

    Donc si je pouvais me retrouver avec une machine 64-bit mais avec des pointeurs 32-bits, je serais super content.

    Maintenant est-ce que sera une architecture supplémentaire ? une option ?
    Est-ce que debian va créer un x32-64 ?

Suivre le flux des commentaires

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