Reprise du message précédent :

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

Et l'avantage de laisser en module, c'est que si celui-ci plante, il ne plante pas *forcément* le noyau.

Ok merci a toi.
 
Pour le temps de boot c'est surtout par rapport au temps gagné quand on passe pas 50 ans à charger 50 modules comme sur un kernel de base sur les distrib "desktop" (ubuntu, suse etc)

ben si, le module, quand il est chargé, tourne en espace noyau comme n'importe quel autre partie de icelui. donc un moduloe qui plante peut entrainer le noyau en entier.
 

Oui en fait j'ai pas été jusqu'au bout de ma pensée; mais tu as raison.
Ce que je voulais dire aussi, c'est que si le module plante, tu peux le décharger et recharger. Pas besoin de redémarrer la bécane.

Je drapalise aussi, sujet intéressant .
 
donc.

Puisqu'on est dans l'optimisation, Shake est un organiseur/défragmenteur pour linux, il déplace les fichiers de façon à minimiser la fragmentation et à mettre à côté les morceaux qui sont lu à des temps proches :
http://linuxfr.org/2006/08/20/21216.html
 
Pas grand chose à améliorer d'un point de vue utilisateur mais c'est toujours intéressant à lire, la célèbre conférence de Dave Jones, Why Userspace Sucks

Un peu dangereux quand même shake ...
Je l'ai lancé sur mon répertoire racine, et arrivé sur /lib/tls/libc-2.3.5.so , serveur X figé, plus rien ne répond => Reset
 
Au reboot, message genre:
kernel panic: cannot load shared library: file /lib/tls/libc-2.3.5.so is too short
 
NB: je suis en Reiserfs (3.6)

Il t'a bien secoué

 
Y'a une légère amélioration de la réactivité, ça se remarque pas vraiment en utilisation, mais en MAO par exemple, ça permet de descendre à des latences très basses (de l'ordre de la milliseconde). Sur les vieilles machines, la différence est plus flagrante.
 
Sinon, une question pour THRAK: -O2 ou -Os ?

Sur les machines pourrie ça se recent bien en tout cas
 
Sur un Core2Duo ça ne doit pas trop ce voir

et pour les néons, on fait comment ?

je suis pas THRAK mais je répond : ça dépend de ce que tu compiles. Pour le noyau, le Os est parfois plus intéressant que le O2.

 
Justement, pour le noyau. Dans quelle situation le Os est-il plus rapide ?
 
J'aimerais bien voir un exemple parlant. Par exemple un bout de code du kernel et ce que gcc produit comme asm avec O2 et Os (j'arrive pas à en trouver)
 
A noter également que pour un système qui utilise dm-crypt en AES256cbc, la différence entre O2 et Os est flagrante (hdparm -t /dev/mapper/crypt passe de 30 à 70 sur ma machine (amd64))
Edit: Euh, en fait c'est pas la différence entre O2 et Os, c'est la différence entre un kernel i386 et x86_64

s'en parle un poil ici mais pas de bench :
http://lwn.net/Articles/157951/

Ca fait un petit bout de temps que je privilégie l'utilisation des caches L1 et L2, et donc un code plus compact à un code plus "prédictif" mais plus encombrant, et qui force des fetches en "mémoire principale" ...
  Les "cache miss" sont très couteux en cycles machines pour les microprocesseurs actuels (en fait, ça fait un peu de temps que c'est vrai). En plus certaines optims du compilateur (pour gcc en tout cas) représentent un travail qui fait doublon avec la logique de prédiction implantée dans ces mêmes microprocesseurs, AMHA.
 
   AMHA, les optims des compilateurs les plus intéressantes, sont celles que l'on retrouve dans les compilos codés par des personnes qui connaissent l'architecture intime d'un µprocesseur donné dans une archi particulière, voire même si les créateurs du compilateurs et les géniteurs de l'architecture cible ne font qu'un, c'est ce qu'il y'a de mieux (qui mieux qu'eux en connaissent les secrets, les faiblesses et les forces ?)
 
EDIT : L'époque des "microprocesseurs RISC purs", où une grosse partie du boulot d'optimisation, de réagencement/réordonancement du code était en très grande partie à la charge du compilateur, est révolue.

 
Sur la lkml aussi, mais personne n'apporte de réponse claire. Cartaines fonctions sont accélérées par l'une des optims et d'autres en patissent. Au global, ça change rien. Dommage qu'on puisse pas spécifier les options en fonction de la "strate" (Os pour arch, kernel, ipc, fs et O2 pour block, crypto, drivers, net ... )
 

 
C'est pas évident, vu que des versions différentes du compilateur induiront des diff dans les optimisations, et ça change en fonction de l'architecture, du proco, du code compilé, ...
Par définition, le kernel n'est pas optimisé. Il faut bien faire le boulot quelque-part
 
Edit: je vais retester en Os quand-même
 
O2
/dev/sdb2: 274 MB in  3.00 seconds =  91.32 MB/sec (natif)
/dev/md0: 242 MB in  2.72 seconds =  88.83 MB/sec (raid1)
/dev/mapper/swap0: 224 MB in  3.01 seconds =  74.34 MB/sec (aes)
/dev/mapper/crypt0: 220 MB in  3.02 seconds =  72.81 MB/sec (raid1+aes)
 
Os
/dev/sdb2: 272 MB in  3.00 seconds =  90.63 MB/sec
/dev/md0: 242 MB in  2.77 seconds =  87.37 MB/sec
/dev/mapper/swap0: 220 MB in  3.01 seconds =  73.01 MB/sec
/dev/mapper/crypt0: 216 MB in  3.02 seconds =  71.61 MB/sec
 
Ca change pas grand-chose  

Oui, mais justement, les processeurs actuels font déjà une grosse partie de ce boulot (avec le réarrangement des instructions dans le pipeline, les prédictions de tests, etc.), donc comme dit Zzozo l'optimisation du compilo est de moins ne moins utile (voire néfaste dans certains cas...)

 
Les pipelines longs et la prédiction de branchement ne sont quand-même plus autant à la mode que lors du lancement du P4
 
Sans tenir compte du fait que pour la crypto par exemple, les procos qui ont plus de registres et/ou de cache enterrent leurs homologues "intelligents", suffit de comparer un P4, un Athlon64 et un Dothan

Une petite question.  
Quand je regarde dans l'aide de l'option Preemptif dans le kernel et il est conseillé de désactiver cette option, ma question est donc : si j'active Preemptif cela va dégrader les perfs ?

 
Pour faire simple: Non, au contraire, ton système sera beaucoup plus réactif, le coût de la préemption en termes de temps cpu est négligeable par rapport à ce que ça apporte en utilisation desktop

Oups j'ai oublié "pour un serveur"

C'est toujours bon ?

 
C'est plus tendu, ça dépend de la charge du serveur et des services qui y tournent, c'est difficile de conseiller sans "ausculter" ton système. Pour un serveur LAMP classique, dans l'énorme majorité des cas, si ton serveur n'est pas à la limite de ce que le hardware peut supporter, c'est mieux de l'activer. En tout cas, perso, je l'active

La machine n'est pas à sa limite.
En fait je me tourne vers ce sujet car mon iowait est très solicité et ça entraine des blocagew de quelques secondes du système.

 
C'est typiquement là que la préemption peut être efficace. Comme IO scheduler, choisis le CFQ

J'ai ça pour le moment :

J'ai un serveur de type LAMP donc ça serait plutôt deadline nan ?

 
   
 
Le deadline fonctionnera beaucoup mieux que le cfq sur des disques cryptés ou un serveur mysql par exemple, mais c'est le plus "spécifique" des trois; c'est le moins bon choix à moins d'être vraiment sur qu'il convient. Pour un serveur lamp classique, tu es largement mieux avec l'anticipatory ou le cfq.
 
Enfin bon, c'est comme pour la préemption: y'a pas de règle générale, ça dépent trop de l'utilisation.
 
Edit: Essaye avec Preemptible Kernel et CFQ et regarde si tu as encore le problème

J'ai testé en faisant un find et voilà le résultat du top :

Ce qui me parrait bizarre c'est ça : 85.0%wa
 
Merci de ton aide.

Faudrait voir quel(s) est (sont) le(s) process qui provoquent cela.
Parce que ca peut être du aux perfs disque ou E/S de Carte Mère, tout comme ca peut être du à
une attente d'un autre process, d'un service réseau distant, etc...
 
WA c'est qu'il attends quelque chose, pas obligatoirement une E/S sur disque

Ca se passe quand des gros accès au disque sont effectués.

Le mode préemptif a une incidence inconstestable pour les applications qui fontde la manipulation de données en temps réel.
 
D'ailleurs pour les applications les plus critiques de ce domaine ce n'est pas un noyau PREEMPT qu'on emploie mais un noyau patché RT (RealTime). Cela est valable dans toutes les grosses applications orienté audio/video (traitement temps réel de flux parfois très importants) et il est recommandé d'utiliser également un système de fichier supportant les transferts temps réel de gros volume de données (je pense à XFS avec le drapeau realtime activé).
 
Cela étant d'après ce que j'ai pu voir sur le net je suis sceptique quand à la pertinence de GNU/Linux pour ce type de traitement surtout si l'on tient compte qu'il s'agit encore de fonctionnalités très expérimentales ; visiblement de nombreuses améliorations seraient encore nécessaires pour pouvoir en faire un véritable système temps réel.  
A vrai dire des systèmes GNU/Linux sont parfois utilisés à côté de certains UNIX dans le domaine du temps réel mais il s'agit de développements sur-mesure, donc avec du code et des applis "maison" spécifiques et les noyaux utilisés sont considérablement modifiés en interne et non plus grand chose de comparable avec ceux qu'on trouve sur kernel.org    
 
 
 

Je n'ai pas de réponse simple et toute faite à cette question (forcément)    
 
Avec l'optimisation -Os GCC génère un code avec des structures plus réduites et une taille plus légère du code. La différence n'est pas flagrante à l'exécution du point de vue des perfs : -Os utilise en fait toutes les optimisations de -O2 mais en désactivant certaines très spécifiques de façon à ne pas faire croître la taille du code ; d'un côté on perd un peu en terme de performances brutes mais d'un autre côté on gagne en ressources à l'exécution (rapidité et légèreté).
 
Pour un environnement desktop sans doute que -Os est plus adapté (si l'on se place dans le cadre de la réactivité du système de la même manière qu'avec la question de la préemption). Pour un environnement serveur je pense que -O2 est a préférer de même que je désactiverai également la préemption : 1) le léger gain de réactivité apporté par -Os et PREEMPT ne se fera pas sentir et il n'y aura pas de réel dégrèvement de performances  2) la stabilité est à privilégier avant le reste aussi on évitera la possibilité de générer du code buggé avec certaines version de GCC (quand -Os est utilisé) et on évitera certains "comportements à risque" du noyau en cas de charge élevée et/ou dépassement de charge occasionnels (quand PREEMPT est utilisé).
 
Un lien intéressant concernant GCC et ses optimisations :
   ---> http://www.linuxjournal.com/article/7269
 
 
De mon point de vue si je dois installer une distro :  
 
- sur des postes serveurs : Debian stable (avec un suivi spécifique des mises à jour) + -O2 + Deadline (dans le cas d'un serveur de fichier ou LAMP) + politique de sécu adaptée aux besoins (chroot, patchs de sécurité type GR ou SELinux)
 
- sur des postes dédiés à une utilisation desktop/station de travail : Debian stable ou testing (avec un suivi spécifique des mises à jour) + -Os + CFQ + certains backports si nécessaires
 
- sur des postes dédiés à une utilisation desktop/multimédia/bidouille : Debian unstable + -Os + PREEMPT + CFQ + tout le lot d'autres trucs considérés "instables" et "déconseillés"  
 
 
Par mon expérience j'ai tendance à considérer qu'il ne faut pas utiliser à la légère -Os (j'ai eu le cas de certains modules buggés lors de leur construction avec certaines versions de GCC 3.x ; avec les versions 4.x ça semble plus sûr) et PREEMPT (problèmes avec certains modules également ou avec certaines règles udev).

rapidement, après je lirai le topic, :
 
le noyau c'est Linux tout court, le tout c'est GNU/Linux, mais le noyau n'a rien de GNU (bon ok, GCC, GNU GPL .... mais bon).

flag

une interview de jens Axboe (entre autre créateur de l'ordonnanceur CFQ) qui explique beaucoup de choses sur le sujet :
http://kerneltrap.org/node/7637

Very interesting, j'ai pris le temps de tout lire tranquillement  

Voici un rapide récapitulatif des points les plus marquants selon moi :

- les versions antérieures à la branche 2.6.x ne disposaient que d'un ordonnancement très basique (pour ne pas dire pourri   ) ; le noyau a ainsi été à la traîne à ce niveau jusqu'à fin 2002, où les choses ont commencées à s'améliorer avec l'arrivée et le développement d'algorithmes d'ordonnancement réellement évolués sous Linux.
Intéressant quand on sait que certains serveurs tournent toujours en 2.4.x (sisi, ça existe toujours   ), sachant que l'ordonnancement joue un rôle particulièrement important dans ce domaine, plus spécialement pour les serveurs de fichiers ou de bdd.

- du point de vue historique, notons qu'un ordonnanceur nommé "linus elevator" a tout d'abord fait son apparition dans la branche 2.6.x ; né d'après une idée de Linus Torvalds, son rôle a été d'apporter quelques améliorations à partir de l'ordonnanceur de base pour pallier à certaines de ses limitations. Il sera abandonné par la suite notamment en raison de son manque de souplesse.

- deadline a été le premier ordonnanceur a introduire un algorithme offrant un meilleur contrôle des entrées/sorties, en se basant sur des unités temporelles pour le traitement des requêtes (et non sur un nombre donné de requêtes par segment comme auparavant, ce qui présentait l'inconvénient de beaucoup dépendre du disque dur et de sa géométrie).
Le principe est d'attribuer une certaine durée de vie aux requêtes qui sont alors ordonnancées en fonction de leur ordre d'expiration ; l'avantage est d'optimiser le temps de traitement (les requêtes qui expirent avant d'avoir pu être exécutée en raison d'une forte charge sont relancées jusqu'à ce qu'elles soient exécutées à partir de leur dernière position dans la file de traitement).
deadline a donc davantage pour objectif de réduire les temps de latence que de favoriser des débits I/O élevés : il est destiné aux applications où le temps d'exécution est critique.

- anticipatory incarne l'un des deux principaux ordonnanceurs "intelligents" sous Linux (CFQ est le deuxième, voir plus bas).
Il est basé sur deadline, mais ajoute en plus un mécanisme permettant de réduire les accès disques par anticipation : l'algorithme se base sur le principe de rester en attente pour traiter les requêtes par série lorsqu'elles sont émises successivement par un même processus.
Cela explique pourquoi anticipatory est considéré comme polyvalent : il confère à la fois des temps d'exécution corrects et une bonne bande passante.

- CFQ est le deuxième ordonnanceur "intelligent" sous Linux, succédant à SFQ (qui n'a jamais été vraiment intégré à Linux car supplanté presque aussitôt par CFQ, du même créateur). Après avoir connu 3 révisions majeures au total (l'algorithme développé initialement n'a plus rien à voir avec celui de la révision actuelle introduite à partir de la version 2.6.13 du noyau), CFQ est devenu l'ordonnanceur utilisé par défaut depuis la version 2.6.18 de Linux.
Le concept mis en oeuvre ici est un partage équitable, entre processus, des accès disques par courts intervalles de temps (à la manière de ce que fait l'ordonnanceur système) : au lieu d'être entièrement traitées les unes après les autres, les requêtes des processus se répartissent tour à tour les accès disques quelques fractions de seconde jusqu'à leur complète exécution.
Les avantages en terme de performance sont clairement évidents lorsque plusieurs processus accèdent simultanément aux mêmes données, cas de plus en plus courant dans nos environnement multi-tâches et multi-utilisateurs.

Une note supplémentaire au niveau de CFQ : son auteur indique que cet ordonnanceur est à présent considéré comme parfaitement stable (aucun bug d'ouvert) et propre ; il est dans une phase où des petites modifications et améliorations mineures sont apportées, bien qu'il soit prévu dans le futur qu'il évolue encore (du point de vue de l'interaction de CFQ avec les contrôleurs de disque fonctionnant avec des files de commandes -comme le SATA-II, et du point de vue de la prise en charge des tâches interactives et non-interactives par CFQ).

J'en profite pour quoter ceci :

C'est toujours agréable de voir que des experts pensent la même chose que soi au sujet de XFS  

 
ou en 2.0

   
 
À la limite pour un concours d'uptime je veux bien...  

 
et elle tourne depuis près de 10 ans maintenant (et pas "à vide" )