[gull] sens des informations de lsmod

[Marc SCHAEFER]

On Thu, Dec 09, 2004 at 11:35:25PM +0000, Thierry de Coulon wrote:
> lsmod me donne une liste impressionnante de modules, dont beaucoup indiquent 
> "used by 0".

Ici, le used signifie: si == 0, j'ai le droit de décharger ce module
maintenant. D'ailleurs en 2.2, le déchargement était automatique via
le daemon qui se chargeait des chargements. En 2.4, le daemon est
une tâche kernel qui ne s'occupe plus du déchargement automatique.
Sauf erreur il faut lancer

   # /sbin/rmmod --all

au moins deux fois (ou l'avoir dans une crontab).

Sinon, c'est que le code de ce module est utilisé (référencé) et ne peut
être déchargé.

Les raisons:

   - le code est utilisé car p.ex. le périphérique associé est `ouvert'
     par un processus ou le système: p.ex. fs monté

   - le code est utilisé car un autre module utilise des services de
     ce module.

Pour certains modules, un chargement et un déchargement automatique est
une mauvaise idée: je cite simplement le cas d'une pilote de carte SCSI
(remettre la carte cause en général un reset du bus SCSI, ce qui peut
avoir des conséquences p.ex. sur la position d'une bande; de même pour
le pilote st(4) directement).

Sauf erreur le chargement manuel implique aucun déchargement automatique
par défaut.

Certains pilotes (p.ex. le pilote Promise de certains chipsets SATA)
supportent mal le chargement dynamique car ils réservent beaucoup de mémoire
physiquement contigüe. Après le démarrage du système, la fragmentation
de la mémoire physique empêche cela.  Citons que la plupart des chips
SCSI (y compris certains vraiment vieux) supportent le transfert transparent
de données non forcément contigües via une liste scatter/gather implémentée
en matériel.  Apparemment c'est encore trop cher pour le SATA d'utiliser ces
techniques qui existaient déjà sur les bus DEC en 1980.

> Question No 1: si ces modules sont indiqués par lsmod, je suppose qu'ils sont 
> chargés et occupent donc de la mémoire, si je comprends bien sans être 
> utilisés (il y a par exemple les modules de toute une série de chipsets: 
> intel_mch_agp, amd_k7_agp, etc....)

Oui, et en plus ils emploient de la précieuse mémoire kernel non
swappable comme tous les modules kernel. Heureusement pas sous forme
contigüe: le code kernel est après le MMU du point de vue du CPU, le
code peut ainsi être éclaté sur plusieurs `pages' (de 4kB p.ex.
sur Intel ix86 sans fioritures).

> Question No 2: si la réponse à la première question est positive, comment 
> faire pour éviter leur chargement?

Il faut procéder au chargement dynamique. A la demande. Ou adapter
manuellement (voir plus bas).
 
> J'ai trouvé dans /etc/modprobe.d un fichier agpgart qui contient une longue 
> ligne "install agpgart /sbin/modprobe --ignore-install agpgart && ..." 
> contenant par exemple tous les modules précités. Si je les enlèves tous, sauf 
> intel-agp qui est celui nécessaire à ma machine, est-ce que je casse tout?

Les pilotes agpgart ne sont nécessaires que si un serveur X tourne (ce
qui n'est jamais le cas sur un serveur). Et il n'est pas forcément
nécessaire dans tous les cas de les charger.

Déterminer quel est le chipset de la carte graphique et ne charger que
celui-là.

PS: sur des machines modernes, on a souvent assez de mémoire pour que
quelques centaines de kilobytes de RAM gaspillée, même non-swappable, ne
soit pas une catastrophe. Si votre configuration ne permet pas un tel
`gaspillage', alors recompilez un kernel avec juste ce qu'il faut, sans
modules -- un kernel monolithique prend toujours moins de place qu'un
kernel modulaire. Ce travail est cependant complexe, et je le répète,
n'est pas un investissement intéressant sur des machines avec 512M de
mémoire et plus.

Quelques informations supplémentaires (de Configure.help):

   /dev/agpgart (AGP Support)
   CONFIG_AGP
     AGP (Accelerated Graphics Port) is a bus system mainly used to
     connect graphics cards to the rest of the system.
   
     If you have an AGP system and you say Y here, it will be possible to
     use the AGP features of your 3D rendering video card. This code acts
     as a sort of "AGP driver" for the motherboard's chipset.
   
     [ ... ]
   
     You should say Y here if you use XFree86 3.3.6 or 4.x and want to
     use GLX or DRI.  If unsure, say N.

Ensuite les pilotes spécifiques:

   Intel 440LX/BX/GX/815/820/830/840/845/850/860 support
   CONFIG_AGP_INTEL
     This option gives you AGP support for the GLX component of the
     XFree86 4.x on Intel 440LX/BX/GX, 815, 820, 830, 840, 845, 850 and 860
   chipsets.
   
   CONFIG_AGP_AMD_K8
     This option gives you AGP support for the GLX component of
     XFree86 on an AMD Opteron/Athlon64 using the on-CPU GART.

typiquement ce dernier j'a probablement pas tellement d'utilité sauf si
vous avez une machine 64 bits.