Le dernier noyau Linux publié est le 6.10 et il incorpore le travail d'Eric Biggers qui a cherché à optimiser les performances de l'algorithme de chiffrement AES.
Cet algorithme est notamment utilisé, dans son mode d'opération AES-XTS, pour chiffrer nos disques durs via le standard LUKS et l'outil cryptsetup.
Avec les disques SSD le débit de données est très important et tous les accès au disque dur doivent donc passer par ces phases de chiffrement ou de déchiffrement. Les performances des primitives cryptographiques du noyau sont donc cruciales pour ne pas subir de ralentissement.
Curieux de constater le résultat du travail d'Eric Biggers j'ai lancé le benchmark avec un noyau 6.9.10 (l'ancienne version) et avec un noyau 6.10 (la nouvelle version).
Voici les résultats (la machine est un laptop avec un Intel de la génération Alder Lake modèle i7-1260p) :
On constate bien un progrès très important pour l'algorithme AES-XTS 256 bits qui passe d'environ 4670 MiB/s à 7870 MiB/s soit une progression de 68%.
Ce n'est pas tous les jours qu'on empoche ainsi un tel gain et cela permet d'utiliser sereinement le chiffrage de votre disque dur sous Linux sans avoir à payer ça par une baisse des performances.
# Chouette
Posté par Luc-Skywalker . Évalué à 10.
Quelle nouvelle réjouissante.
Merci à toi pour l'info hyper intéressante et merci au dev pour le boulot.
"Si tous les cons volaient, il ferait nuit" F. Dard
# Ajout de code en assembleur
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Je suppose que le gain de perf vient de cette partie du commit Git:
Ajout d'un code assembleur AVX ("Advanced Vector Extensions").
Lien vers le code : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/crypto/aes-xts-avx-x86_64.S
[^] # Re: Ajout de code en assembleur
Posté par patrick_g (site web personnel) . Évalué à 6. Dernière modification le 24 juillet 2024 à 14:54.
En fait on voit dans le mail de récap d'Herbert Xu (mainteneur officiel de la partie crypto du noyau) qu'il y a eu plusieurs commits cumulatifs d'Eric Biggers optimisant aes-xts :
crypto: x86/aes-xts - add AES-XTS assembly macro for modern CPUs
crypto: x86/aes-xts - wire up AESNI + AVX implementation
crypto: x86/aes-xts - wire up VAES + AVX2 implementation
crypto: x86/aes-xts - wire up VAES + AVX10/256 implementation
crypto: x86/aes-xts - wire up VAES + AVX10/512 implementation
crypto: x86/aes-xts - make non-AVX implementation use new glue code
crypto: x86/aes-xts - access round keys using single-byte offsets
crypto: x86/aes-xts - handle CTS encryption more efficiently
crypto: x86/aes-xts - handle AES-128 and AES-192 more efficiently
crypto: x86/aes-xts - eliminate a few more instructions
crypto: x86/aes-xts - optimize size of instructions operating on lengths
crypto: x86/aes-xts - simplify loop in xts_crypt_slowpath()
[^] # Re: Ajout de code en assembleur
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 24 juillet 2024 à 18:39.
Curieux je ne vois pas d'amélioration (je viens de mettre à jour mon Arch pour passer au 6.10).
Ça veut dire quoi "modern CPU" d'après toi ? Le mien a l'air d'avoir les instructions AES concernées non ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ajout de code en assembleur
Posté par patrick_g (site web personnel) . Évalué à 5.
Je pense qu'il faut le support VAES (Vector AES) qu'on trouve dans le jeu d'instruction AVX-512.
# nice
Posté par ouafnico (site web personnel) . Évalué à 5.
sur ma machine j'obtiens 52% d'augmentation sur le même test.
Cela reste impressionnant
# [HS] Pourquoi des captures d'écran?
Posté par Zenitram (site web personnel) . Évalué à 7.
J'ai l'habitude de recevoir des captures d'écran pour du texte venant de mon logiciel ou de ligne de commande, mais comme ces personnes sont pas expertes j'évite de les "attaquer" la dessus, mais ici les personnes écrivant sont sensée mieux connaître donc je pose la question qui me trotte dans la tête depuis un moment : pourquoi cette habitude de faire une capture d'écran de texte plus facile à copier/coller dans un mail ou journal LinuxFr que capture d'écran à découper et stocker (sans parler de son "poids" inutilement plus élevé pour la même information)?
[^] # Re: [HS] Pourquoi des captures d'écran?
Posté par patrick_g (site web personnel) . Évalué à 10.
Un tableau de chiffres tu peux écrire ce que tu veux comme résultat alors que la capture d'écran c'est la "preuve irréfutable" que le gain est réel :-)
Non en fait ça m'a juste paru plus simple que de galérer avec la syntaxe markdown pour coller les résultats.
[^] # Re: [HS] Pourquoi des captures d'écran?
Posté par BAud (site web personnel) . Évalué à 10. Dernière modification le 25 juillet 2024 à 01:29.
hein ?!
```bash au début et ``` à la fin, et c'est marre…
[^] # Re: [HS] Pourquoi des captures d'écran?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6.
Oui c'est plus simple que de galérer à trouver un endroit où héberger l'image.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: [HS] Pourquoi des captures d'écran?
Posté par BAud (site web personnel) . Évalué à 2.
imgur fait généralement le taf' même si une fiabilisation du cache de LinuxFr.org + stockage pérenne (genre archive.org) permettrait d'avoir ceinture et bretelle
[^] # Re: [HS] Pourquoi des captures d'écran?
Posté par Tonton Th (Mastodon) . Évalué à 6.
Pour être compatible Instagram ?
[^] # Re: [HS] Pourquoi des captures d'écran?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Perso, j'aurais bien aimé voir un joli "plot" plutôt que d'avoir à parser la capture d'écran.
[^] # Re: [HS] Pourquoi des captures d'écran?
Posté par BAud (site web personnel) . Évalué à 2.
et donc après parsing + plot ça donne quoi ? :D (tu peux héberger sur imgur comme patrick_g< :p)
je n'ai qu'un kernel 6.6.42 pour fournir les infos sur ma machine :/ (cauldron suit les kernel LTS pour les fournir en Mageia stable aka 9 ensuite, donc bon 6.10 attendra)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.