Noyau Linux

Connaissance libre | Logiciels | Logiciels libres | Gnu/Linux > Distributions | Ubuntu

Liens

Versions et nouveautés (news, release notes)

Docs noyau

Actu / articles

Livres/bouquins

Docs

Sources

  • kernel.org (the kernel archive - sources, patchs, git, changelog, dernier noyau stable, mailing-lists, etc.)
  • lxr.linux.no (naviguer dans les sources de toutes les versions du noyau Linux)
  • Docs LDP
  • paquet : linux-source-x.x.x

Wikipédia

Infos techniques

Infos : voir Debug - récolte infos
Paramètres noyau
Boot - démarrage PM QoS (Quality Of Service) Interface

Timers
Configuration du noyau Linux (fichier .config)

Compilation du noyau Linux

Versions du noyau Linux

  • Versions : infos fr
  • 3.8 : Les microprocesseurs i386 ne sont plus supportés à partir de cette version
  • 3.7 : supporte ARM et le SecureBoot (plus d'infos)

Optimiser les ressources du noyau

Versions du noyau & améliorations notables

Optimisations autres que celles du noyau

Tutos/articles/doc/howto

Ordonnanceur de tâches (processus scheduler)

  • Algorithmes
    • CFS, un O(log N), auquel a participé Ingo Molnár, est utilisé à partir du noyau Linux 2.6.23. Le scheduler O(1) était utilisé dans les versions précédentes 2.6.
    • etc.

Ordonnanceur au niveau E/S (I/O scheduler)

  • Tutoriels : Linux 2.6 IO Performance Analysis, Quantification, and Optimization, tutos SSD
  • Dans la plupart des distributions GNU/Linux récentes, le I/O scheduler défini par défaut est CFQ (qui peut/devrait être avantageusement remplacé par BFQ
  • Comparaison entre bfq, cfq, deadline, et loop
  • Pour un serveur de base de données
    • basculer sur le I/O scheduler deadline permet de meilleures performances dans certains cas.
    • le I/O scheduler noop est également plus performant que cfq dans certains cas. A utiliser avec les SSD. A utiliser dans le cadre d'un serveur virtualisé, ce qui permet de tirer profit du I/O scheduler de la machine hôte (qui pourrait être par exemple "deadline").
  • Modifier dynamiquement le I/O scheduler, par exemple pour sda :
    • vérifier le I/O scheduler utilisé (c'est celui qui apparaîtra entre crochets)
      • # cat /sys/block/sda/queue/scheduler
      • # cat /sys/block/cciss?c0d0/queue/scheduler
    • basculer vers le I/O scheduler "deadline"
      • # echo "deadline" > /sys/block/sda/queue/scheduler
      • $ echo deadline | sudo tee /sys/block/sda/queue/scheduler
  • Modifier le I/O scheduler pour les "reboot" ultérieurs
    • dans le fichier de config de grub (/boot/grub/grub.cfg, grub.conf,menu.lst), ajouter à une entrée noyau le paramètre elevator=deadline, et rebooter sur ce noyau.

Modification de paramètres noyau lors de sa compilation

  • Plus d'infos
  • Ex : optimisation au niveau périphs (d durs)
    • # Generic PCI (IDE chipset & Bus Master DMA) support
      # Use DMA by default

Modification de paramètres noyau dynamiquement, par /proc

  • Ex au niveau thread : modifier threads-max 
    • # echo 120000 > /proc/sys/kernel/threads-max

Modification de paramètres noyau par sysctl

Modification dynamique
  • mettre les paramètres à modifier dans un fichier "modifs", et exécuter :
    • # sysctl -p modifs
Modification statique (active pour les "reboot" ultérieurs)
  • Tutos
    1. Tutos sécurité
  • Procédure  (autre exemple)
    1. vérif : # sysctl -a
    2. ajouter à /etc/sysctl.conf (ou aux fichiers du dossier /etc/sysctl.d) les paramètres voulus, ou les y modifier
      • Ex, pour un ordinateur avec 6 Go de mémoire, dans /etc/sysctl.conf :
        • kernel.shmall = 1495122   (taille mémoire physique / taille page mémoire)
          kernel.shmmax = 3062009856   (taille mémoire physique / 2)
    3. prise en compte de la modif : # sysctl -p

Optimisation noyau pour les bases de données PostgreSQL

  • Optimisation noyau pour les bases de données Oracle (pour DB2)

    • Vérification des limites (# ipcs -l) et de l'usage (# ipcs -a)
    • Si nécessaire, modifier les limites des paramètres suivants
      1. vérif : # sysctl -a
        • kernel.shmmax = .......  ( recommandé : moitié de la mém vue par : $ free -b)
        • kernel.sem =  250   32000  100    128
        • kernel.sem = semmsl semmns semopm semmni
      2. modif, à ajouter/modifier dans /etc/sysctl.conf :
        • kernel.sem =  250   256000  100    1024
      3. prise en compte de la modif : #  /sbin/sysctl -p
    • Notes
      • kernel.shmmax = taille max (en octet) du segment de mémoire partagée
      • kernel.sem = paramètres sémaphores de /proc/sys/kernel/sem :
        • semmsl  : nb max de sémaphores par tableau
        • semmns : nb max de sémaphores système  (semmns = semmsl * semmni)
        • semopm : nb max d'ops par appel semop
        • semmni  : nb max de tableaux (d'identifiants de sémaphores) - semaphore ID limit

Paramètres - options de boot

Lors du boot, des paramètres (ou options) peuvent être passés au noyau Linux vmlinuz, par exemple au niveau du fichier de configuration de grub.

Logs du boot

Voir les paramètres du noyau Linux qui ont été utilisés au boot

  • $ cat /proc/cmdline
  • Ou : voir dans /boot/grub/grub.cfg (ou menu.lst) les paramètres qui suivent vmlinuz

Liste et description de ces options

Quelques options

  • acpi=off   (peut solutionner un pb de boot, mais risque de désactivation des ventilateurs)
  • apm=on   (pour activer le pilote APM, note : APM est de + en + remplacé par ACPI)
  • boot_delay=1000   (laisse le temps de faire une photo d'écran en cas de crash au boot)
  • elevator=deadline   (choix de cet ordonnanceur E/S)
  • mce=ignore_ce   (désactive mcelog, au cas où la carte mère surveillerait déjà les défaillances RAM)
  • quiet   (évite l'affichage des détails du boot)
  • reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] | p[ci] | f[orce]
  • selinux=0   (désactive SELinux)
  • vga=1, ou vga=791   (permet l'affichage d'un + grand nb de lignes, utile en cas de besoin de photo d'écran)
  • vconsole.keymap=us
  • vconsole.font=

Multi-coeurs

  • le noyau Linux SMP le supporte
  • certaines applis les utilisent
    • ex : ffmpeg -threads 2

Linux, optimisation et temps réel

cset, cpuset

C-states (C0, C1, etc.), P-states, T-states

T-states : Thermal states.

P-states : fréquences du microprocesseur.

2 types de C-states : les C-states ACPI BIOS (pilote Linux acpi_idle), et les C-States (ou C-modes) du microprocesseur (pilote Linux cpuidle ou intel_idle).

Les extensions C-states et MWAIT du microprocesseur peuvent être utilisées par le s.e. pour réduire la consommation d'énergie (suivant le niveau du C-state, certains éléments du microprocesseur peuvent être au repos (non-alimentés) ou la tension peut être baissée). Inconvénient : temps de latence lors de la transition d'un C-state à un autre. C0 est le mode 100% opérationnel (C0 = perf. max, car C1, C2, etc. vont entraîner une consommation d'énergie réduite mais également des temps de latence).

Vérif
  • $ dmesg | egrep "idle|C-state"
  • $ egrep "idle|C-state" /var/log/messages - pour RHEL, SLES, etc. (/var/log/syslog pour Ubuntu)
  • $ cat /proc/acpi/processor/CPUx/power  (x = n° du coeur) - affiche "active state", "max_cstate", "maximum allowed latency", les temps de latence, etc.
  • $ find /sys/devices/system/cpu/cpu0/cpuidle -name name -o -name latency | xargs cat  - affiche les C-states avec leur temps de latence en microsecondes)
  • $ cd /sys/devices/system/cpu/cpu0/cpuidle/statex ; for i in `ls` ; do echo $i: ; cat $i ; done   (x = n° du C-states)
  • $ acpitool -c
  • $ turbostat affiche les fréq. (+ basses ou + hautes (turbo-boost)) et des statistiques concernant les C-states (statistiques idle)
Réglages statiques (au reboot) du C-state, par les paramètres du noyau Linux
  • intel_idle.max_cstate (si à 0, désactive les C-states du microprocesseur et active les C-states ACPI)
  • processor.max_cstate (C-state ACPI)
Réglages dynamique (sans reboot) du C-state

 - par la commande cpupower  - par des programmes du paquet tuned (RHEL 6 et +)
Embarqué
Liens

Fréquence(s)

  • HZ : Internal kernel timer frequency (The frequency the system timer interrupt pops).
    • Robert Love explique la variable HZ
    • HZ=100 : ok pour serveurs
      • interrupt toutes les 10 ms (1/100e de s.)
      • uptime wraparound (jiffies wraparound) : tous les 497 jours.
    • HZ=1000 : ok pour PC de bureau (musique, vidéo, etc.)
      • interrupt toutes les 1 ms (1/1000e de s.)
      • ++ préemption + rapide
      • - - risque de overhead (car 10x plus d'interrupts qu'avec HZ=100) => mais pas de pb sur ordinateurs rapides...
      • - - uptime wraparound (jiffies wraparound) : tous les 49,7 jours, ce qui peut poser pb.
      • note : est-ce cela qui est défini dans linux-rt et linux-headers-rt ?
    • HZ est défini ((par CONFIG_HZ)) dans le fichier de config du noyau Linux, ou dans le module config_hz_info.c.
    • A partir de la version du noyau Linux 2.6.13, HZ est passé de 250 à 1000 sur certaines distrib. (ex : RHEL).
  • Configuration & infos
    • CONFIG_HZ : permet à un utilisateur de modifier la valeur de HZ.
      • Dans /usr/src/linux.../kernel : Kconfig.hz et time/Kconfig
      • Dans /usr/src/linux.../.config
  • Vérification
    • # grep HZ /boot/config-`uname -r`
      • CONFIG_HZ=250  (sur Ubuntu 11.04 et 10.10 32 bits).
    • # getconf CLK_TCK  (correspondrait à USER_HZ)
      • = 100 sur Ubuntu 11.04 et 10.10 32 bits.
    • Shell-script
      • #!/bin/bash
        while [ 1 ] ; do
        A=`cat /proc/interrupts | grep "timer interrupts" | cut -d ':' -f 2 |sed -e 's/[^0-9]//g'` ; sleep 1 ; B=`cat /proc/interrupts | grep "timer interrupts" | cut -d ':' -f 2 |sed -e 's/[^0-9]//g'` ; C=$(($B-$A)) ; echo "$C HZ"
        done

Différencier la configuration "noyau" de celle des applications

PTP

PTP (Precision Time Protocol) est un protocole distribué (au niveau LAN) d'horloges synchronisées (au 10e de micro-seconde, donc PTP est beaucoup plus précis que NTP). La synchronisation se fait tout au long de la chaîne, au niveau logiciel (s.e. RHEL 6.5, etc.), et au niveau matériel (NIC, switchs, etc.).
Domaines d'applications : trading, etc.

NTP

$ cat /var/lib/ntp/ntp.drift

Tracing du noyau & des processus (IRQ, wakeup, etc.)

Infos & liens"Linux temps réel"

Le "temps réel" est en fait une prédictabilité de temps de réponse.

Problèmes

kernel tainted (gâté, infecté, souillé)

Un noyau "tainted" indique qu'un module a une licence non-GPL, ou qu'il y a (eu) un problème: une erreur noyau, un "hang", etc.

Vérifications

  • $ cat /proc/sys/kernel/tainted   (si cette commande affiche une autre valeur que 0 => kernel tainted)
  • $ dmesg | grep -i taint

Plus d'infos

Debug - récoltes infos

Voir aussi debug.htm

Docs - articles

Packages à installer

  • # yum install kernel kernel-devel debuginfo-install systemtap yum-utils

Logs

  • # dmesg
  • Fichiers du dossier /var/log : messages, dmesg, dmesg.0, dmesg.1.gz, boot, boot.log, bootstrap.log

Infos noyau (boot, config, driver, module, etc.)

Scripts de récupération d'infos

Config du noyau Linux

  • Infos
  • Fichier de configuration des sources
    • /usr/src/linux/.config
    • /usr/src/kernels/$(uname -r)/.config   (RHEL, etc.)
  • Paramètres noyau
    • # sysctl -a
  • Configuration du noyau en activité
    • Fichier de configuration : /boot/config-$(uname -r)
      • Ex : vérification du support par le noyau d'initrd et de loopfs
        • $ grep -E "CONFIG_BLK_DEV_INITRD|CONFIG_BLK_DEV_LOOP" /boot/config-$(uname -r)
    •  /proc
      • Ex : vérifier la valeur de threads-max (et éventuellement la modifier)
        • # cat /proc/sys/kernel/threads-max

Infos des drivers présents sous la forme de module

Infos

  • cat /proc/modules
  • depmod -n `uname -r`

Infos par lsmod et modinfo

  • for i in `lsmod | awk '{print $1}'` ; do echo "=== $i" ; modinfo $i | grep -E "version:|vermagic" ; done   (version)
  • for i in `lsmod | awk '{print $1}'` ; do echo "=== $i" ; modinfo -n -k `uname -r` $i ; done   (localisation des binaires)

Ex : périph CD/DVD et driver associé

# lsmod | grep -E 'cd|dvd'
     cdrom  ...  sr_mod
# modinfo sr_mod
     filename:     .......sr_mod.ko
     description:  SCSI cdrom (sr) driver

Ex : module NFS

  1. # lsmod | grep nfs && modinfo nfs
  2. # cat /sys/module/nfs/srcversion
  3. # ls -l /lib/modules/3.2.0-26-generic/kernel/fs/nfs

Infos des drivers intégrés au noyau, et leur configuration

  • Ex : recherche de driver NFS
    • # grep -i nfs /boot/config-$(uname -r)
    • # grep -i _nfs /usr/src/linux/.config
    • # grep -i _nfs /usr/src/linux-headers-`uname -r`/.config      (Ubuntu)
    • # grep -i nfs /usr/src/kernels/......./.config                            (RHEL)
    • # gzip -cd /proc/config.gz | grep -i nfs                                 ((Mandriva))

Drivers tiers

  • $ jockey-gtk   (gestion des drivers tiers (AMD, nVidia, réseau wifi, etc.))

Mes autres infos "drivers, firmwares"

Debug du noyau et des drivers

Le noyau Linux supporte kdb et kgdb à partir de la version 2.6.26-rc1.

Infos et liens

Outils

Tracing
Dumper / crash dump avec kdump
Debug

Commencer un debug, par exemple avec kdb

  • # echo g > /proc/sysrq-trigger

Mécanisme "Magic SysRq" (ou Sys Rq, System request)

Docs : SysRq et "command keys", Ubuntu fr, Wikipédia, Wikipedia
Les infos seront affichées sur la console, ou par la commande dmesg, et/ou dans /var/log/syslog et /var/log/kern.log.

Quelques "command key"
  • h : aide
  • d : liste les locks
  • t  : liste l'état des tâches
  • c : simule un crash et créée un crash dump - utile quand Linux est bloqué (hang), ça fait partir le noyau Linux en kernel panic (system crash)
  • e : envoi du signal SIGTERM à tous les process, sauf à init
  • i : envoi du signal SIGKILL à tous les process, sauf à init
  • s (sync), puis u (umount), puis o (shutdown), ou b (reboot) - utile quand Linux est bloqué (hang state)
2 solutions pour envoyer une commande au noyau (récolte d'infos, ou reboot, etc.)
  • En modifiant /proc/sysrq-trigger
    • # echo "la_command_key" >  /proc/sysrq-trigger
    • Exemple : # echo "h" >  /proc/sysrq-trigger
  • Par les touches clavier
    • Alt + Syst + "la command key"    (Syst (ou SysRq) est la touche "Impr écran", à droite de F12)
    • Exemple : Alt + Syst + h
Note : l'opération par le clavier n'est possible que si /proc/sys/kernel/sysrq est à 1
  • Vérifier si le mécanisme est actif
    • # cat /proc/sys/kernel/sysrq
  • S'il ne l'est pas, activer les magic keys dynamiquement
    •   # echo 1 > /proc/sys/kernel/sysrq
  • Activer les magic keys au reboot : dans sysctl.conf
    • kernel.sysrq = 1   (sysrq actif ou pas)

En cas de Linux bloqué (hung/hang), shutdown ou reboot par "Magic SysRq"

Tout en maintenant enfoncées les 2 touches Alt SysRq, taper - au choix - ces command key SysRq :
  reisuo     o => shutdown
  reisub     b => reboot

Périphériques

La gestion des périphériques, de leurs devices (lspci, ls /dev) et de leurs drivers/modules est assurée par devfs (gestion statique), ou par udev (gestion dynamique) dans certaines distributions (récentes).

udev

Infos Wikipédia
Mes infos systemd
Plus d'infos sur udev, tutoriel udev
Config
  • /etc/udev/udev.conf
  • /etc/udev/rules.d (utilisé au boot, mais les modifs de ces fichiers sont également prises en compte à tout moment ; + d'infos dans son README)
    • 70-persistent-net.rules (pour les devices réseau), etc.
  • /lib/udev/rules.d (+ d'infos dans son README)
Commande udevadm
  • $ udevadm info --query=all --name=/dev/sda   (liste les attributs du périphérique /dev/sda)
  • $ udevadm info -a -p $(udevadm info -q path -n /dev/sda)    (de même, avec infos parents)
Debug
  • Pour logger d'éventuelles erreurs, ajouter à /etc/udev/udev.conf : udev_log="err"
  • Pour un debug dynamique : udevadm control --log-priority=info

Loadable Kernel Modules (LKM)

Ces modules sont des éléments de noyau (pilotes, systèmes de fichiers) chargeables dynamiquement.

Docs Configuration - fichiers de config pour la construction du initrd
  • /etc/sysconfig/kernel (nom des modules à intégrer dans le initrd)   - RHEL, SLES, etc.
Configuration - fichiers de config
  • /etc/modprobe.conf (noms des modules à charger ou à désactiver au boot)   - RHEL 4, etc.
    • ex : alias edac_core off   (au cas où la carte mère surveillerait déjà les défaillances RAM)
    • Doc locale : man modprobe.conf
  • /etc/modules.d/le_module.conf
  • /etc/modules (noms des modules à charger au boot + leurs paramètres)   - Debian, Ubuntu, etc.
  • /etc/modprobe.d/                                                                                                   - Debian, Ubuntu, RHEL 6, etc.
    • blacklist.conf (noms des modules à ne pas charger au boot)
      • ex : blacklist edac_core   (au cas où la carte mère surveillerait déjà les défaillances RAM)
    • nom_du_module.conf (paramètres de ce module)
  • sysfs : /sys/module
Modules
  • Dans /lib/modules/`uname -r`
    • /lib/modules/`uname -r`/modules.dep (dépendances entre les modules), modules.dep est créé par la commande depmod)
  • Exemple : module NFS
Chargement au boot
  • init, par son script /etc/init/module-init-tools.conf, lit le fichier de config /etc/modules et charge les modules par la commande modprobe (Ubuntu)
  • udev se charge du chargement des modules dans certaines distrib (ayant une version récente du noyau)
Commandes
  • # lsmod
  • # insmod (charge un module - kerneld utilise insmod pour charger automatiquement des modules quand c'est nécessaire)
  • # rmmod
  • # man -k modprobe
  • # man -k modules.dep
Infos sur les modules
  • $ modprobe --showconfig
  • # find /sys/module | grep version | grep -v srcversion
  • # cat /etc/modules (modules chargés au boot)
  • Exemple : module NFS
  • Lister les modules chargés dans le noyau : lsmod   (mise en forme de /proc/modules).
    • # lsmod | grep -E 'Module|nom_du_module'
    • # lsmod | grep nfs && modinfo nfs
  • # modinfo nom_du_module
  • autre commande : modprobe, qui affiche moins d'infos
    • # modprobe -l
    • # modprobe -l nom_du_module
Outil "module assistant" (commande : m-a)
  • gère des paquets de modules (destinés à un ou plusieurs noyaux), aide à les construire et les installer
  • exemple DRBD (avant qu'il soit intégré au noyau Linux 2.6.33)
    • # apt-get install module-assistant
    • # cd /usr/src ; tar -zxvf drbd.tar.gz ; cd /usr/src/drbd/modules
    • # m-a prepare
    • # m-a automatic-install drbd-module-source

Clock

Infos dans la section "Notes" du man 8 hwclock
  • There are two main clocks in a Linux system
    • The Hardware Clock...
    • The System Time...
  • How hwclock Accesses the Hardware Clock...

Mémoire

Config boot et modules

Au cas où la carte mère surveillerait déjà les défaillances RAM, au niveau du noyau Linux :

Exemples de config paramètres

Mes autres infos mémoire


A propos de GNU/Linux

GNU/Linux est un système d'exploitation multi-tâches, multi-fenêtres, libre et gratuit. GNU/Linux est constitué du noyau Linux, des programmes GNU, et d'autres programmes. D'autres noyaux que Linux peuvent être utilisés avec GNU (micro-noyau Hurd, etc). Cette page-ci est consacrée au noyau Linux.

Vic
Page modifiée le 28 janvier 2018
Page d'accueil du site