Linux-kernel version-2.6 complexification-2.6

From UnixWiki

Le noyau 2.6 a apporté pas mal de nouvelles façons de fonctionner, visant à améliorer plusieurs aspects (performances, évolutivité, ...). Cette évolution s'est faite au prix d'une plus grande complexité dans le code. Etant donné que le développement du noyau doit toujours viser des performances maximales, des structures sont mises en places pour optimiser le code. On se trouve alors face à une multitude d'outils utilisés dans le noyau, et qu'il faut connaître.

Prenons l'exemple de l'allocation de la mémoire. A la base, on peut allouer de la mémoire avec malloc et la libérer avec free dans un programme en C. Comme le noyau n'a pas accès à la bibliothèque libc, on doit généralement faire appel à l'une des deux alternatives: kmalloc/kfree ou vmalloc/vfree. Il faut déjà faire le choix entre ces deux possibilités, en fonction de la nécessité ou non d'avoir un emplacement mémoire dont les adresses physiques sont contiguës.

Etant donné que les allocations et libérations de la mémoires prennent du temps, et aboutissent à une fragmentation de la mémoire, il a été mis au point le système des slab. Il s'agit d'un système de réservation de la mémoire pour stocker des listes d'objets et qui ne sont libérés qu'en cas de réelle nécessité, c'est à dire en cas de manque de mémoire. Le développeur doit indiquer par une variable si la donnée stockée est nécessaire ou non. Quand on n'a plus besoin de la donnée, on la garde malgré tout en mémoire. Le système se chargera de libérer la mémoire en cas de besoin. D'une part, cette technique évitera de libérer de la mémoire et de la réallouer plus tard si on fait à nouveau appel à cet objet. D'autre part, l'objet n'aura pas besoin d'être rechargé depuis le disque en cas de besoin.

Cet exemple montre qu'au lieu de manipuler une seule technique basique d'allocation et de libération de la mémoire, on doit connaître une multitude de techniques, ainsi que les structures et les fonctions qui sont associés. Les optimisations du noyau 2.6 conduisent à la multiplication des techniques de ce type à connaître.

D'ailleurs, quand on essaie de lire le code du noyau, on se rend rapidement compte de ce problème. Il est parfois difficile de localiser le code qui est responsable d'une fonctionnalité en particulier, tellement il est fait appel à des fonctions extérieures. Lorsqu'on suit les appels de fonctions pour essayer de remonter au instructions qui sont exécutées, on se trouve à nouveau confronté à d'autres appels, et on trouve très peu de code sur place. Il est donc plus difficile d'analyser le code source que pour le passé. Malgré tout, il n'est pas question de revenir en arrière sur ces avancées, mais il faut être conscient de cet inconvénient