Bonjour à tous !    
 
 
Comme il existe déjà un topic dédié sur le noyau Linux, je ne reviens pas sur les dernières news, les versions disponibles, où l'obtenir, comment l'installer/le compiler, etc.
 
Pour ces questions là, merci de consulter le topic en lien ci-dessous :
   ---> http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
 
 
Mon idée est en fait de proposer ici un espace réservé pour toutes les questions concernant la configuration du noyau Linux proprement dite.  
 
Le but n'est pas vraiment de passer en revue de A à Z toutes les options existantes pour simplement parvenir à configurer un noyau (on aurait pas fini autrement   ), mais plutôt de discuter de certaines d'entre-elles et de la bonne façon de les règler en vue d'optimiser ou au moins de configurer finement son noyau.
 
 
Les retours d'utilisateurs pourront donner des indications plus précises sur l'activation ou non d'options particulières (par ex. comme le découpage mémoire, les modes de latence, les ordonanceurs, etc. ou encore certains drivers laissant apparaître des signes d'instabilité).
 
Comme on ne connait pas toujours bien leur influence exacte (peu de documentation ou alors parfois réservée aux experts), je pense qu'a terme ce sera utile pour tous ceux (dont moi   ) qui cherchent à y voir plus clair et savoir dans quel cas utiliser ou pas tel ou tel paramétrage (les besoins diffèrent beaucoup selon qu'on installe un serveur, une station de travail, un desktop ou encore de l'embarqué) ou quel paramétrage est tout simplement à éviter (inutile, obsolète ou bien dangereux).
 
 
J'attends donc vos avis, retours, conseils sur ces questions    
 
 
 
PS:
Soyons détendus, de bonne humeur, en évitant les remarques et  trolls du genre "c'est nul comme sujet, ça sert à rien la compilation" ou "optimiser son noyau c'est débile de toute façon on gagne rien en perfs". Au pire, on considèrera que le tuning/l'optimisation de son noyau c'est inutile donc indispensable  
 
PPS:
Une synthèse des différentes discussions est disponible ci-dessous.

-- RÉCAPITULATIF DU TOPIC OPTIMISATION --
------------------------------------------------------------
 
 
Ceci est une sorte d'index qui met en valeur les points les plus intéressants qui on été abordés au fil du topic.
Utile donc pour les gens pressés ou en prévision du jour où ce topic atteindra sa 5000ème page.      
 
 
 
 
SUJET N°1 : ORDONNANCEMENT
 
 
Sous Linux, nous pouvons distinguer deux principaux types d'ordonnancement :
- l'ordonnancement des tâches (process scheduling)
- l'ordonnancement des accès disque (I/O scheduling)
 
Il est important de ne pas mélanger les deux, puisque l'ordonnancement des tâches consiste à d'attribuer aux processus en cours d'exécution des priorités plus ou moins élevée en fonction de leur importance, tandis que l'ordonnancement des accès disque consiste à adopter une stratégie visant à minimiser les accès en lecture/écriture sur les disques dur.
 
Nous abordons ici, au moins dans un premier temps, l'ordonnancement des accès disque. Le but est de passer en revue les différentes stratégies d'ordonnancement existantes, en vue de choisir l'ordonnanceur le plus adapté, et donc optimisé, selon le type d'usage de son ordinateur (desktop, serveur, etc.).
 
 
1) I/O scheduler par la théorie
 
- Pourquoi vouloir se préoccuper de l'ordonnancement  ? :
   ---> http://forum.hardware.fr/forum2.ph [...] =0#t833697
 
- L'ordonnancement par Jens Axboe (développeur des principaux ordonnanceurs dans Linux) :
   ---> http://kerneltrap.org/node/7637
   ---> http://forum.hardware.fr/forum2.ph [...] =0#t888421
 
- Les recommandations d'IBM pour l'ordonnancement :
   ---> http://www-128.ibm.com/developerwo [...] duler.html
 
 
2) I/O scheduler par la pratique
 
- Vérifier l'ordonnanceur utilisé par sa distribution, le changer au besoin :
   ---> http://forum.hardware.fr/forum2.ph [...] =0#t833498
 
- Tester les différences, gains ou pertes de performances entre les ordonnanceurs :
   ---> FFSB (Flexible File Sytem Benchmark) - http://sourceforge.net/projects/ffsb/
   ---> Autres utilitaires (FS et plus) - http://wiki.linux-nfs.org/index.php/Testing_tools
 
 
Voilà pour l'instant ; à suivre...  

En parlant de tuning noyau, on peut changer les differents algos de scheduling par exemple par des algorithmes genetiques, l'auteur des patchs dit avoir obtenu une amelioration sensible des performances, ce qui reste a vérifier, mais je trouve l'idee interessante.
 
Plus d'infos içi ou là

Confirmation: Le scheduling, c'est bien l'ordonancement des tâches gérées par le CPU ?
 
J'avais vu qqpart qu'il était possible de passer d'un ordonanceur à l'autre en changeant le contenu d'un fichier (dans /sys je suppose). C'est possible ? Si oui, ça permettrait relativement facilement de faire un test de gain/perte de perfs...

Oui : le sheduling, c'est le choix du processus (ou du thread) que le système va envoyer au CPU pour l'exécuter.
 
 
Vu qu'on a l'air parti pour parler de scheduling, est-ce que quelqu'un sait si quelque chose a été fait pour l'ordonnancement des threads sur des machines à accès mémoire non uniforme (NUMA) ? J'ai entendu dire que c'était l'un des gros problèmes d'ordonnancement auquel sont confrontés les fabriquants de gros calculateurs (et je pourrais bien avoir à en utiliser un de ces jours)
 
 
 
PS:

Drapo too - Gentoo inside

Merci pour ces premiers commentaires.  
 
Comme le sujet a été lancé, effectivement, pourquoi ne pas introduire le topic en discutant dans un premier temps des ordonnanceurs ; essayons de nous y intéresser au moins sur quelques posts histoire de déjà réunir quelques détails/précisions à ce niveau.  
 
 
 
> ArthurDent :
 
Oui, j'ai également entendu parler de ces algos génétiques ; ça paraît prometteur et certains patchs sont certainement à suivre/tester car susceptibles à terme d'être inclu officiellement dans le noyau.
 
Pour l'instant je n'ai encore rien essayé à ce niveau, mais d'ici la fin du mois je compte me monter une bécane spécifique pour le bidouillage sous GNU/Linux ; à ce moment-là je ne manquerai pas d'essayer plusieurs patchs "exotiques" de ce genre et de faire part de mes impressions. Si tu es intéressé et que tu as l'opportunité de tester ce type d'ordonnanceur, n'hésite pas à nous tenir au courant également.
 
 
 
> darkpenguin :
 
Oui, généralement en anglais on parle de I/O Scheduler pour désigner l'ordonnanceur sous GNU/Linux.
 
C'est possible de changer d'ordonnanceur, et les possibilités sont souples à ce niveau-là, ainsi on peut le faire d'après ce que j'ai pu lire à ce sujet :
 
- lors du boot (pour tous les disques), en passant l'option elevator=nom_de_l'ordonnanceur
Pour vérifier l'ordonnanceur utlisé au boot :
   --->   dmseg | grep scheduler
 
- lors de l'exécution du système (pour le(s) disque(s) de son choix), par l'interface /sys (cf. explication plus bas)
Pour vérifier l'ordonnanceur utilisé à l'exécution par disque :
   --->   cat /sys/block/périphérique/queue/scheduler
 
La deuxième possibilité s'avère particulièrement intéressante pour attribuer un ordonnancement précis en fonction d'une utilisation donnée par disque (pratique dans le cas d'un serveur faisant à la fois serveur de courrier et serveur de base de données par exemple). Evidemment, elle l'est donc également pour les benchs.
 
 
Changement d'ordonnancement, un exemple pratique :
 

 
Je peux donc voir ici que le scheduler utilisé par défaut sur sdb est 'CFQ' ; maintenant changeons voir d'ordonnancement :
 
- dans un premier temps je charge le module de l'ordonnanceur voulu (par souci d'optimisation je ne compile en dur que celui utilisé par défaut, les autres étant compilé en modules).

 
- enfin je change l'ordonnanceur simplement en passant en paramètre le nom de l'ordonnanceur voulu au fichier scheduler.

 
Et voilou, c'est tout    
 
 
 
> franceso :
 
Comme je n'ai pas trop l'occasion d'approcher des systèmes NUMA, perso je ne me suis pas encore documenté à ce sujet, donc pour ma part je n'ai aucune idée...

Autre information, pour ceux intéressés par des benchs au niveau FS et ordonnanceurs, parmi les utilitaires couramment employés, il y a Flexible File System Benchmark (licence GPL).
 
   ---> http://sourceforge.net/projects/ffsb/
 
 
D'autres utilitaires sont listés et réunis sur la page ci-dessous, à noter qu'ils ne sont pas tous spécifiques à l'ordonnancement.
 
   ---> http://wiki.linux-nfs.org/index.php/Testing_tools
 
 
Voilà de quoi faire  

drapal

aussi

dites vous savez qu'il existe pour mettre un "drapeau" sauf que la c'est une étoile, pour marquer les topics intéressants
 
 

Oui mais ça montre pas à l'auteur le soutiens qu'on lui apporte !

Absolument, le est un encouragement et montre à l'auteur que l'on va suivre son topic
Alors que le bookmark c'est pour les lurkeurs

exact.
moi j'aime ce topic...  
et je mourrirais pour sa survie...
 
 
 
 
eh, enfin non.
 

 
J'avais testé il y a un moment, cela fontionnait mais sans faire de benchs difficile de voir les améliorations de performances. Et en ce moment ça me tente bien de retester mais downloader les sources du noyal en 56k spa pratique donc je ferais ça en septembre.

Y a des gens ici qui ont fait des comparaisons des modes préemptif et non préemptif ?
 
En regardant le topic des 'uname -a', j'ai vu que plein de gens mettent leur noyau en préemptif (je suppose pour accélérer la réactivié pour un pc de bureau), mais je me suis toujours demandé si on voyait effectivement une différence lors d'une utilisation "normale" de son desktop...

ben moi je vais le désactiver carpas compatible avec mon dongle wifi.
je te tiendrais au courant

Juste pour signaler que si je ne m'abuse, il ne faut pas confondre 2 choses :

• le process scheduler qui est l'ordonnanceur des tâches et dont l'algorithme est en O(1)  (le fameux ), son but est d'ordonner les tâches, i.e. de dire qui tourne et quand.
• le I/O scheduler qui est l'ordonnanceur de lecture/écriture sur le disque, dont le but est de minimiser les temps d'accès et déplacement des têtes en réordonnant les accès disques, c'est celui là qu'on choisit (cfq, deadline, anticipatory, noop)  http://www-128.ibm.com/developerwo [...] duler.html

quelques articles d'IBM sur le tuning pour les serveurs zseries (mais ça doit s'adapter au reste)
http://www-128.ibm.com/developerwo [...] index.html

Sujet fort intéressant aussi, et généralement c'est difficile de trouver des d'informations objectives à ce niveau.  
Certains parlent d'une sensible amélioration de la réactivité du système (en utilisation desktop), d'autres ne voient pas de différences, et encore d'autres disent rencontrer des problèmes de stabilité ou des problèmes avec certains périphériques.
 
Ce serait vraiment utile aussi de savoir de quoi il retourne, je me suis aussi posé pas mal de fois la question en compilant mes noyaux : faut-il l'activer, ne pas l'activer, l'activer, ne pas l'activer ?    
Bref je me demande s'il existe une possibilité de vraiment mesurer sérieusement le rapport performance/stabilité obtenu entre les modes non préemptible, préemptible volontaire, et préemptible faible latence. Quelqu'un sait-il s'il existe un outil, un bench pour vérifier cela ?    
 
Pour l'instant je suis bêtement les recommendations fournies par Linus et son équipe :  
 -> Non préemptible : utilisation serveur
 -> Préemptible volontaire : utilisation station de travail, desktop
 -> Préemptible faible latence : utilisation desktop multimedia, embarqué
 
A noter, vous l'aurez peut-être remarqué, qu'en mode préemptible faible latence l'option Preempt The Big Kernel Lock permet de choisir si l'on souhaite rendre préemptible ou non la section critique du noyau. Apparement cela aurait un certain impact en utilisation desktop, mais peut-être que certains problèmes de stabilité et certains problèmes avec des périphériques peuvent en découler. A nouveau je n'en sais rien, jusqu'ici je n'ai pas encore activé les options préemptibles.
 
 
 
> Mjules :
 
En effet, précisions intéressantes, je parlais d'ordonnancement au niveau du disque dur effectivement et non au niveau des processus.
Le lien sur les I/O scheduler est intéressant, j'ai aussi fait quelque recherches et j'ai pu noter que certaines distributions (Novell/SUSE Linux 9 et +, RedHat Enterprise 4) ont adoptées le CFQ scheduler par défaut. Il serait intéressant de savoir quels sont les schedulers choisis par défaut dans les noyaux des différentes distributions (Debian, Fedora, Gentoo, Mandriva, RedHat, Suse, Ubuntu, etc.)
 
Pour finir, auu niveau du process scheduler, il n'y a pas possibilité pour l'utilisateur de vraiment gérer son comportement, ou je me trompe    On ne peut jouer sur les processus que par le biais des nice/renice non ?

anticipatory pour mandriva 2006

Ben c'est à ce niveau la qu'interviennent les modes preemptifs, temps réels et faible latence, tu veux quoi de plus

 Ok c'est noté, je fais une liste ci-dessous que je complèterais avec vos infos au fur et à mesure
 
 
Liste des I/O Scheduler employés par défaut dans les principales distributions :
 

 
Note: ces informations sont susceptibles de changer (et donc de ne plus être justes au moment où vous lisez ce post), dépendant des choix des distributions au fil du temps.
 
(à suivre)

Je pense que ce que THRAK voulait dire, c'est qu'il n'est pas possible de changer la stratégie de process scheduling : le noyau est compilé dans l'un des modes (non-préemptif, préemptif volontaire / faible latence) ; ensuite, il n'est pas possible de changer.

Savoir s'il existait des outils s'exécutant au niveau de l'espace utilisateur et permettant d'interagir sur le comportement des processus. Je verrai une utilité à cela pour pouvoir gérer soi-même certains processus dans le cadre d'une utilisation SMP par exemple ; il peut être intéressant de pouvoir attribuer manuellement des processus par CPU. Ainsi. tu pourrais réserver l'utilisation d'un processeur à une tâche précise, etc.

Exact    c'est bien ce que je voulias dire (cf. mon exemple précédent, pouvoir adopter soi-même une stratégie pour l'ordonnancement de certains processus par ex.)

A priori, pour le 2.6.18, CFQ sera celui par défaut donc pas besoin de faire de liste pour ça(ils vont tous y passer)
mais tu peux en faire une pour le preempt/non-preempt  

Comme tu casses tout toi      
 
Bon allez, j'adapterais ma liste alors pour le PREEMPT  

De base sur ma Debian.

Ce type de chose existe au moins pour les architectures NUMA (on revient à mon post du début) : pour ce type d'architecture, il est essentiel de pouvoir contrôler la localisation des processus (lourds et légers) pour éviter au maximum la délocalisation de la mémoire après un changement de contexte. Aux dernières nouvelles (mais c'est à confirmer), aucun ordonnanceur n'est capable de déterminer efficacement le processus le plus adapté à un processeur donné. Pour pallier ce problème, on a donné à l'utilisateur la possibilité de fixer lui même le(s) processeur(s) sur lesquels il veut voir s'exécuter un processus. Une API numa a été définie pour le noyau, et s'accompagne de la bibliothèque C correspondante libnuma, ainsi que de l'outil numactl.
 
La question est de savoir si cette API est bien implémentée dans le noyau, et si ce type d'outils est aussi utilisable pour des architectures multi-processeurs à accès mémoire uniforme (ce qui pourrait être bien pratique comme THRAK le suggère).
Je n'ai pas trop  le temps de chercher de la doc à ce sujet en ce moment, mais je le ferai sans doute un jour et je vous tiendrai au courant.

Ca apporte quoi exactement ? Un temps d'accès moin long ?
Sur le lien proposé par Mjules sur les I/O scheduler il est écrit que Anticipatory optimise le mouvement des têtes de lecture, on le sent vraiment ?

Avec un ordonnanceur les temps d'accès et les débit en lecture/écriture peuvent être améliorés.  
 
C'est plus particulièrement important dans des environnements exécutant des opérations qui font un usage intensif du disque dur, car cela peut avoir un certain impact du point de vue applicatif (performance) ou matériel (durée de vie).
 
Mais ce n'est pas simple, les besoins en ordonnancement varient selon le type d'application pour lequel un disque dur est utilisé. Différents ordonnanceurs sont donc proposés et chacun est plus ou moins optimisé et donc approprié pour un usage précis.
 
Chaque ordonnanceur à donc une stratégie qui lui est propre, en rapide résumé :  prédiction des requêtes I/O (Anticipatory), mise en cache des requêtes I/O (Deadline), multiples requêtes I/O (CFQ), et qui le destine à un usage donné :  Anticipatory -> polyvalent mais pas optimisé, Deadline -> stockage / base de données, CFQ -> desktop / multi-utilisateurs.
 
Choisir un ordonnanceur qui n'est pas adapté à un usage, ce n'est donc pas seulement risquer de se priver d'un gain de performances, c'est risquer de se trouver avec des performances encore moindres que sans aucun ordonnancement.

Merci !
Donc pour une serveur d'hébergement PHP/SQL il serait préconisé d'utiliser Deadline ?

 
le meme sur dapper

   C'est l'ordonnanceur qui semble le plus adapté en effet.

+1

 
 
sur fedora core 5 x86-64

Sur Centos 4.4 (x86), je n'ai pas le fichier "scheduler" dans /sys/block/sda/queue ! (sda étant mon disque dur)
Où est-il passé ?

Drapal
 
Deux petites questions :
 
- Connaissez-vous un outil pour "benchmarker" son noyau ?
Il y a bien bootchart pour voir le temps de boot, c'est pas mal, mais après ?
 
- Est-ce que rajouter des modules à la compilation rend le kernel plus lourd/lent même si on ne charge pas ces noyaux ? Quand je compile, j'hésite souvent entre garder tel driver en module (manette usb, wifi etc) ou non quitte à le recompiler plus tard si besoin...

En parlant des I/O Scheduler
 
J'ai installé une gentoo en Reiser4 sur mon portable, et j'avais lu dans une doc que le Deadline pouvait être bien adapté à ce FS, ainsi qu'à une utilisation en laptop pour limiter les accès disques (et donc laconsommation qd on est sur batterie).
 
Gentoo n'utilise pas vraiment de scheduler par défaut, dans la mesure où il faut choisir ses sources du noyal et les compiler à l'install... celui par défaut est donc celui du .config par défaut des sources.

Le temps de boot d'un noyau ne permet pas de se faire un avis sur les perfs de celui-ci
Sinon comme outil, ben ca depends ce que tu veux tester, les perfs en I/O, en calcul, etc...
 

Si c'est le cas, c'est vraiment négligeable, l'interet de compiler en dur le strict minimum c'est surtout interessant dans le cadre de systèmes embarqués avec de fortes contraintes sur la mémoire disponible