salut,
 
bon je vient de lire des posts assez compliques (j ai absoluement rien compris en gros ), notamment sur le kernel, et autres joyeusetes
 
donc si ca vous dit, on se fait un petit topic warlodz sur le kernel et les autres trucs assez technique de linux (genre ... heu ... bah plein de trucs en fait )
 
 
voila, en fait j aimerai ke ca devienne un topic pour les non inities comme moi, pour decouvrir les faces cachees (mais utiles) de linux
 
 
 
 

Genre quoi ?

spa compliqué ... suffit de savoir lire ...
 

OK moi j'ai une question !!
 
C'est quoi un scheduler ? Et pourquoi le scheduler O(1) il est mieu que celui qu'est dans le noyau actuellement ?

 
genre le topic ke tu (je crois) as fais sur le patch pour le kernel, ki regroupe plusieurs patches pris a gauche a droite
 
bah j ai rien compris de ce ke vous discutiez

 
c est valable pour tout ca
 
depuis kan les sdf ki vivent sous une tente post sur OSA d ailleurs ??

 
c'est un sdf nerdz, il a un pc dans sa tente

 
Tres grossierement, le scheduler est le chef d'orchestre du systeme : tu as plein de taches qui arrivent en meme temps, et lui spécifie selon des priorités et autre ordre d'arrivée qui doit passer avant, qui peut prendre la place de qqun d'autre, qui peut prendre plus de temps... C'est lui qui s'occupe de la commutation des taches selon des criteres bien définis.  
 
Actuellement le scheduler est en O(n). Ca veut dire que le temps que met le scheduler pour faire son travail est proportionnel au nombre de tache se trouvant dans sa file d'attente. Il doit parcourir cette file pour déterminer qui va être élue tache courante ( je schématise, ceux qui en savent plus me corrigeront si je dis des betises ). Si n est le nombre de taches en attente, alors on dit que la "complexité" est en O(n), c'est à dire linéaire en fonction du nombre des tâches. Avec le nouveau systeme, quelque que soit le nombre de tache en file, il faudra toujours un temps CONSTANT au scheduler pour faire son travail, on dit que la complexité est en O(1).  
 
Voilà Hésitez pas à me corriger !
 
@+

moi, ce que j'aimerais bien savoir, c'est ce qu'est le linkeur, et pourquoi il est parait il si lent sous Nux (ou GNU, si c'est pas du kernel) et comment on pourrait l'améliorer, si c'est prévu etc.

Passke je me tate encore ...
Mais je vais essayer de passer la nuit dans mon lit, histoire d'exorciser un peu ce très très mauvais souvenir ...

Bon, il faut bien que quelqu'un se lance, alors j'y vais...
 
 
 
 
 
 ALORS LES TAPAITTES ON RECOMPILE LA KERNAILLE !  
 
 
 
 
 
 
 
 
 
 
 
 
Désolé de polluer  

 
La phrase mytique  

SALUT LES TAFIOLLES!!! KOMAN ON RECOMPIL LA KERNELLE ???????????????!!!!!!!!!!!!??????????????????? MAGNEZ-VOUS JAI PA QUE CA A FAIRE !!!!!!!!!!!/MGS ME !!!!!
 
Je me souviens plutôt d'un truc comme ca

 
Ha nan spo moi qui l'ai fait ce tomiks sur le ck6. et pis le ck6 c juste un ensemble de patchs reunis dans un paquets pour corriger qq faiblesse du noyau 2.4, et backporter des trucs sympas du 2.5  
 
Mais bon voila hein, la theorie sur a quoi ca sert et ce que ca fait, autant ca se trouve sur le net, autant savoir comment ca se code ou s'interprete a vrai dire ca me dépasse  

 
d ou l interet du topic
 
 
 
sans vouloir me la peter ou autre, j aimerai faire un topic serieux, vraiment serieux, sur les particularites techniques du kernel et tout ce ki va autour
 
car de la doc complexe, c cho a trouver, alors ce ki ont les connaissances, n hesitez pas a la partagez avec les pauvres ignorants ke nous sommes (non Jar Jar, ne te fais pas prier s il te plait )

 
allez, une bonne nuit de sommeil, un peu de ciment et d huile de coude et il n y paraitra plus
 
si ca vous ennuie pas, j aimerai k on continue tout ce ki est HS sur bla²@ASA  

Chui assez d'accord avec le principe, en gros se faire une doc technique avec nos connaissance, une espece de what-is comme les how-to

 
ça ça m'interesse bcp aussi !

Bin quand un programme est compilé, on ne met plus l'intégralité des bibliothèques dans l'exécutable. Elles sont recherchées par /usr/bin/ld dans la phase finale de la compilation (l'édition des liens), et pour chaque bibliothèque, on regarde dans le fichier le SONAME (champ montré par objdump -p). Au final le binaire contient plein de champs REQUIRED avec des sonames de bibliothèques dedans (objdump -p les montre).
 
Quand on lance le binaire /usr/bin/toto, on va en fait chercher /lib/ld-linux.so.2 /usr/bin/toto comme quand un script perl qui commence par #!/usr/bin/perl (on peut voir le /lib/ld-linux.so.2 avec less monbinaire, et exécuter /lib/ld-linux.so.2 monbinaire, ça marche). /lib/ld-linux.so.2 est un binaire statique fourni avec la libc, qui s'occupe de lire le fichier ELF et de regarder les dépendances. Pour chaque champ REQUIRED, il va chercher le fichier de ce nom dans les répertoires définis par /etc/ld.so.conf (c'est pour ça qu'il y a des liens libtoto.so (utilisé par -ltoto) -> libtoto.so.4 (= le soname) -> libtoto.so.4.12.89 (= la véritable lib)), et ainsi de suite récursivement. Ensuite, il regarde dans la table des symboles (objdump -T) de tous ces fichiers et il recherche tous les symboles manquants, histoire de remplacer l'adresse 0 par l'adresse où on pourra effectivement trouver la fonction dans la mémoire. Une fois tout ça résolu, on peut lancer le programme.
 
C'est cette dernière opération qui est assez longue. Le linker GNU n'est pas spécialement lent, mais il y a souvent beaucoup de bibliothèques à résoudre car les programmeurs de logiciels libres aiment bien réutiliser le code, et le font de la manière la plus élégante, avec des bibliothèques dynamiques. Exemple, galeon : 62 bibliothèques, 2700 symboles dans le seul binaire (en pratique il y en a encore plus). Et il faut refaire l'opération à chaque module dynamique qu'on charge avec dlopen (genre les plugins xmms).
 
La solution actuelle pour améliorer ça, c'est le prelinking. Ça consiste à utiliser un algorithme bien reproductible pour mapper les bibliothèques en mémoire, et à noter dans chaque binaire la position de tous les symboles une fois pour toutes. Problème 1, il faut refaire l'opération dès qu'une des bibliothèques est mise à jour, puisque les offsets des adresses changent. Problème 2, l'implémentation est pourrave puisqu'elle modifie les binaires alors que techniquement rien n'empêche de mettre tout ça dans un cache centralisé.

 

 
 
commencer par m'expliquer pourquoi la suse a un kernel qui accélère à ce point la bureautique !  

 
   
bah voilà ! là j'ai l'impression d'avoir gagné ma journée au moins

 
bon, klk un desirai mieux comme explication ??
 
nan, je ne pense pas, merci Jar Jar

 
c ce ke je me disais !!
 
pourtant elle avait pas ete tres productive la mienne jusqu a lors

ah si, quand même, une tite question : ce linkeur, il change bcp pour le passage au kernel 2.6 ? y-a du mieux ? ou ça a pas bougé ?

 
Ca c ce qu'on appele une illusion, ou l'auto-persuasion

 
non, c'est 911gt3 qui a testé => compilation d'un kernel suse sous deb ... parait que ça ressemble enfin à qq'chose niveau perf ... moi perso j'ai recompilé mon kernel avec le patch aa uniquement, et ça n'a rien changé (enfin pas flagrant)
par contre je suis carrément passé à suse, et c'est le jour et la nuit, je peux te dire que ce n'est pas de l'autopersuasion  
tout est plus rapide en ce qui concerne la bureautique

Heu perso je l'ai recompiler son kernel suze, et je n'y ai rien vu du tout le seul truc c que ca m'a permis de faire un peu le ménage et d'epurer mon .config     chui repasser a un 2.4.20 de kernel.org + le patch ck6 et celui de la console en frame buffer, et c tout aussi bien.

 
et t'as déjà essayé avec un kernel deb ? p-t que c'est lui qui merde
et pour ck je n'ai jamais vu la dif ... mais je ne les applique pas tous non plus, je suis ce qui est dit dans la doc

 
 
 
ptain, vous m'avez donné envie là!
 
j'ai recompilé le mien.
 
 
Circonstance atténuante N°546545 :  
 
j'avais oublié de le compiler avec le --fomit-frame-pointer        

 
je crois qu'a partir de 02 ca y es direct nan ?  

 
nan, ça n'y est plus depuis le 3.2 (ou p-t même le 3.0)
parce qu'il peut parait-il et théoriquement y avoir des cas où ça merde
reste que la plupart des distro continuent de l'activer par défaut pour la compilation du kernel et autre ...

Dans les src du 2.4.20, le makefile contient une partie pour l'activer par défaut il me semble.
Moi ce que j'aime c ce genre d'optim qu'on trouve sur les forums gentoo:
 
-O3 -march=athlon-xp -mcpu=athlon-xp -mfpmath=sse -msse -mmmx -m3dnow -pipe -fomit-frame-pointer -ffast-math -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4  
 
   
 
La je pense que y'a kk risque de perturber un peu le kernel

 
y-a aussi qq redondance par contre là

C klair ! Mais comme on dit, "au moins la chui sure"    
 
chui sur qu'en plus ca doit creer un kernel plus gros au final  

 
si ils arrivent pas à avoir un kernel plus gros avec ça, c'est qu'il se démerde mal
enfin tant qu'il s'amuse pas à compiler sa libc avec

Comme expliqué, il vient avec la libc, pas avec le noyau.
Par contre, on peut imaginer un noyau qui optimise les accès disque sur les fichiers mappés en mémoire pour que cette opération soit plus rapide.
 
Par contre il y a eu des changements substantiels qui ont amélioré les performances avec la glibc 2.3.

En plus ce n'est pas ça qui va changer quelque chose. Le temps passé dans le noyau lui-même est en général très faible, donc gagner quelques % de vitesse avec des optimisations, c'est ridicule.
 
Par contre, il est beaucoup plus réaliste de réduire les latences du point de vue des applications en modifiant certains algorithmes (genre le scheduler, le buffer cache...) dans le noyau.

 
ayant casse 2 fois la libc sous openbsd, je peux vous assurer ke la recompiler est un danger  
 
 
 

Attention, confonds pas tout : ces flags gentoo ne sont pas utilisés pour compiler le kernel, mais pour le reste au contraire !

Jar Jar >    merci beaucoup.