[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [HS] Noyau personnalisé contre noyau générique



maderios a écrit :
On 10/24/2014 03:06 PM, BERTRAND Joël wrote:
maderios a écrit :
On 10/24/2014 10:40 AM, Stéphane GARGOLY wrote:

Je suis - juste - un peu plus prudent concernant le gain de réactivité
qu'aurait généré un noyau personnalisé mais, bon, cela doit
certainement
dépendre de l'ordinateur.

Je constate vraiment de meilleures performances, sinon je ne me serais
pas enquiquiné à compiler des centaines de noyaux depuis 15 ans...

     J'aimerais bien avoir des chiffres pour savoir de quoi on parle.
Autant sur des sparc64 ou alpha, c'est intéressant, autant je demande
franchement à voir sur du x86. C'est intéressant sur l'alpha parce que
le noyau de base est compilé pour un ev4 qui n'a pas les extensions BWX,
donc qui se coltine un adressage bâtard pour accéder à un octet. Donc,
dès qu'on utilise un truc supérieur à l'ev56 inclus, il est intéressant
de recompiler son noyau.

     Pour un x86, l'architecture du processeur ne change pas assez pour
avoir une significative différence de performance en recompilant son
noyau avec un -mtune ou un -march (même en virant le code qui n'est pas
utile à sa configuration particulière).


     Tu aimes vivre dangereusement. Le noyau vanilla est considéré
aujourd'hui comme un noyau de développement, charge aux distributions de
le stabiliser. Par ailleurs, certains pans du noyau ne sont correctement
compilés que par une version bien précise de gcc.
Quel danger? Les maj de sécurité sur kernel.org sont immédiates... J'ai
rencontré moins de problèmes (ex pour l'audio et la carte graphique)
avec les sources du noyau originales qu'avec les sources Debian.
Question gcc, j'utilise la 4.9 (Sid)

Je parle de la stabilité du noyau. J'ai eu assez de problèmes sur architectures non x86 pour ne plus jouer à cela. Parce que le noyau sparc64 qui compile et fonctionne parfaitement avec un gcc 4.5 et qui merdoie allègrement avec force deadlocks lorsqu'il est compilé avec gcc 4.8, j'ai donné.

Linus lui-même a indiqué sur les listes de diffusion du noyau que le 2.6 de kernel.org était _le_ noyau de développement et qu'il n'y aurait plus de branche de développement.

Pour élargir le sujet, certains paquets Debian ne sont pas au top,
négligés ou inexistants (ex E17 utilisable depuis longtemps) et je
préfère compiler les sources originales. J'ai du virer ce matin le
récent paquet debian Terminology pour cause de comportement étrange,
donc retour à mon paquet compilé perso qui marche à merveille. Idem pour
le paquet deb Mnogosearch qui logue à n'en plus finir et qui était
obsolète ...  Transmageddon, qui ne procurait plus Xvid sauf la vieille
version 0.20 compilée perso. Ouf, Transmageddon 1.4 vient de sortir et
il réintègre Xvid. A compiler sinon il faut attendre en restant sur
l'ancienne version.  Tout ceci pour dire qu'il est avantageux de
compiler certains programmes tout en gardant une base debian fiable.
Cela permet de s'affranchir des délais de maj, de vivre dans une
relative indépendance par rapport à certains choix de Debian, et de
gagner du temps et de la fiabilité,  malgré les apparences.


Ce n'est pas exactement la même chose. Le noyau est ce qui fait la stabilité du système.

	JKB


Reply to: