La version 3.2 du kernel Linux apporte de nombreuses optimisations

Une meilleure autonomie en cas de GPU Intel

Le noyau Linux, composant essentiel des distributions, est paru récemment en version 3.2 pour rappel, et malgré un numéro de version ayant fortement évolué, il s‘agit toujours d’une évolution au même rythme que précédemment.

La version 3.2 du noyau ne contient pas d’ajouts majeurs mais certaines évolutions sont néanmoins importantes. C’est le cas notamment d’une pile TCP réécrite en partie et dont le fonctionnement plus souple doit permettre une meilleure gestion des périphériques réseau. Le système de fichiers ext4 évolue lui aussi et offre la possibilité d’allouer de plus grands blocs ce qui doit permettre de meilleures performances d’accès pour les partages de fichiers et de lecteurs (comme dans le cas de Samba).

Voici d’autres améliorations présentes :

Les GPU Intel profiteront de leurs fonctions d’économie d’énergie grâce à une optimisation du pilote
Support de l'architecture Hexagon de Qualcomm
De nouveaux pilotes Wi-Fi plus stables
Diverses optimisations pour le système de fichiers Btrfs
Support de l’allocation fine et des snapshots récursifs sur le Device Mapper

Ce sont là des extraits d’une liste plus complète que l’on peut consulter depuis le site Kernel Newbies.

Comme d’habitude, la mise à jour du noyau sera diffusée progressivement aux distributions via les dépôts officiels.

Vincent Hermann

Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.

Twitter

Le 9 janvier 2012 à 17:26 (25 259 lectures)

Actu Précédente Actu Suivante

Il y a 76 commentaires

INpactien

skydevil Le mardi 10 janvier 2012 à 00:12:32 #71

Inscrit le mercredi 31 octobre 07 - 2306 commentaires

animehq a écrit :

Il faut le dire 27 ans d'amour pour le X cela ne s'oublie pas si facilement xd.

En meme temps le barbu est célibataire, donc l'X s'impose...

Bon, plus sérieusement, X a des atouts indéniables par rapport aux autres systèmes, mais il vieillit...

INpactien

GentooUser Le mardi 10 janvier 2012 à 02:34:36 #72

Inscrit le lundi 4 juillet 05 - 1471 commentaires

BenJ... a écrit :

Rien sur le TRIM :( Say moche. Dommage.

Y'a quoi à rajouter ?

INpactien

Quiproquo Le mardi 10 janvier 2012 à 08:31:13 #73

Inscrit le samedi 21 novembre 09 - 929 commentaires

Commentaire_supprime a écrit :

Allez, intégration dans Fedora 17 en mai ?

Sinon, wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.tar.bz2 marche pas mal si tu veux pas attendre le mois de mai (on en sera plus au 3.2 en mai, même si il sera encore maintenu).

Edité par Quiproquo le mardi 10 janvier 2012 à 08:31

INpactien

ben51 Le mardi 10 janvier 2012 à 14:57:06 #74

Inscrit le dimanche 15 mars 09 - 476 commentaires

animehq a écrit :

Il y a Wayland mais il est encore un peut jeune...

Justement wayland est une réponse de la communauté au problème de X.org

INpactien

pafLaXe Le mercredi 11 janvier 2012 à 02:49:04 #75

Inscrit le mardi 19 juillet 05 - 8311 commentaires

lorinc a écrit :

Prends ce code :

int main() {

float *v1, *v2, sum;
unsigned int i;

v1 = malloc(64*sizeof(float));
v2 = malloc(64*sizeof(float));

for(i = 0 ; i < 64 ; i++) {
v1[i] = i*i;
v2[i] = i;
}

sum = 0;
for(i = 0 ; i < 64 ; i++) {
sum = v1[i]*v2[i];
}

printf("%f\n", sum);

return 0;

}

Compile le en -O3 et désassemble le.
On voit clairement les 64 mulss, alors qu'on pouvait allègrement faire16 mulps et aller 4 fois plus vite. Et je te parle même pas de faire du vfmaddps...

Edith: ARG, pci me mange la moité du texte en commençant par le milieu

J'ai pas de quoi testé sous la main en ce moment, mais avec un GCC 4.6+ et un petit -mtune=corei7-avx kivabien ça le fait pas ?

INpactien

Conan28 Le lundi 16 janvier 2012 à 18:11:44 #76

Inscrit le mercredi 13 septembre 06 - 177 commentaires

Schpountz42 a écrit :

Développe ton avis, ca m'intéresse

Je veux dire dire qu'il y a deux mécanismes en place maintenant : Un qui bloque le nombres de pages dirty et un autre qui ralenti l'I/O mais qui est censé régler le trop plein de pages. Je suis pas sûr que limiter à coup de sleep soit la soluce la meilleure, mais étant pas dévelo' kernel, je m'avancerais pas sur ça. Ce qui me gène plus c'est que maintenant ces deux mécanismes font doublon, vu que les deux gèrent une même chose : le flot de page dirty. J'aurais mieux vu donc si on avait viré le "direct reclaming" (second mécanisme ralentissant l'I/O) et qu'on avait implémenté cette solution à la place de ce dernier. Je trouve que ça fait « rustine ».

Il n'est plus possible de commenter cette actualité

Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.