> Pourquoi des options de debug sont-elles activées par défaut dans une distribution définitive qui est releasé auprès du public ?
Il y a toujours du subjectif dans ces choix.
Pourquoi conserver la sortie du kernel (dmesg) si la distribution est sensée marcher sans accro ? D'ailleur cette sortie n'est pas affichée.
Pourquoi fournir SeLinux alors que les programmes livrés ne doivent pas avoir de trou de sécurité et marcher de façon sûr sans SeLinux ?
Pourquoi Fedora détecte les mauvais free (). exemple : "*** glibc detected *** gedit: free(): invalid pointer: 0x0858cb08 ***" ?
etc...
Pour spécifiquement CONFIG_DEBUG_SPINLOCK d'activité, je n'en sais rien.
Pour info, voilà les options de debug du dernier noyau FC6 : CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
On voit déjà que la version de développement à plus de debug. Je ne crois pas 2 second que les CONFIG_DEBUG* de FC6 soit uniquement pour débuggeur le noyau (sauf cas particulier) si c'est au prix d'une perte de performance significatif connue. Et ce pour plusieurs raisons :
- Fedora est développé de façon ouverte et ça gueulerait sévère sur les mailing list.
- Fedora n'a aucun intérêt à fournir un noyau lent, bien au contraire.
- Fedora a la branche développement pour ça et la branche testing pour les mises à jour.
Donc, pourquoi CONFIG_DEBUG_SPINLOCK ?
Voilà mon interprétation (je ne connais pas l'avis de Fedora).
Il va de soit que Fedora est aussi utilisé pour développer des applications. Il est dans les objectifs de Fedora d'être une plateforme pour le développement d'application. Le développement d'appli multi-thread est compliqué et se planter avec les futex est très courrant. Je crois qu'avec CONFIG_DEBUG_SPINLOCK le développeur sait s'il fait un unlock sur un mutex qui n'est pas locké ou sur un mutex créé depuis un autre processus mais dont on n'a pas mis le flag pour l'utiliser en inter-processus, etc... (Je dis peut-être des conneries ici, je n'ai pas vérifié dans le détail).
Génial tout ça !
Le problème est d'évaluer la contre partie. Pour une utilisation de mysql comme dans le bench de ce journal, la contre partie est intolérable (en imaginant que le problème vient de DEBUG_SPINLOCK, je n'en ai pas la preuve, je me suis hazardé dans une explication). Mais si la contre partie est en général une perte de performance de 0,01 %, et que DEBUG_SPINLOCK permet aussi aux développeurs d'appli de développer plus vite, alors DEBUG_SPINLOCK est (peut-être) justifié.
Pour les quelques cas où la contre partie est intolérable, il suffit de recompiler le noyau (les sources c'est aussi fait pour ça).
Notes que FC6 est sorti depuis plusieurs mois et c'est la première fois que CONFIG_DEBUG_SPINLOCK fait parlé de lui.
Un mot sur ce bench. Linux/Fedora a de moins bon résultat que FreeBSD pour un bench et pour un système à 8 cpus (seulement 1 à ce jour).
Et si le bench n'était pas représentatif ?
Et si le bench (ou mysql) avait un bug spécifique pour Linux qui n'impacte pas FreeBSD ? Ce n'est pas exactement le même code (il y a des #ifdef Linux etc..).
Se sont aussi des hypothèses à creuser. Quoique personnellement je ne chercherai pas là en premier. Même si le test est buggé il faut comprendre pourquoi Linux/Fedora s'écroule en monté en charge.
> Ne me dit pas que ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora ! Non ce serait trop machiavélique.....
Pour le troll fait en voulant nous faire croire que tu ne veux pas troller (alors que ce n'est pas la première fois que tu le fais...).
Les CONFIG_DEBUG de RHEL 4 (noyau 2.6.9, dernière mise à jour) : CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
Pour info, RHEL 5 en cours de développement utilise et utilisera un 2.6.18 (compatibilité binaire/source de RHEL oblige). FC6 a actuellement un 2.6.19 (le 2.6.20 ne devrait pas tarder) et la branche de développement de Fedora est en 2.6.20.
> ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora !
Comme tu pourrais dire ça pour Mandriva "classique" et Mandriva Corporate Server, etc...
Comme on pourrait dire qu'Ubuntu débuggue RHEL. Et oui, il y a des paquets dans Ubuntu qui seront dans RHEL. Tous les bug trouvés dans Ubuntu (idem pour Mandriva, Fedora, OpenSuSE, etc) profitent à RHEL (et aussi à Debian Etch :-))
Ta remarque est tout simplement ridicule, grotesque et il serait bon que t'arrêtes.
Et notes qu'en moyenne il n'y a qu'une Fedora sur 3 qui est utilisée comme base de RHEL :
RHEL 3 => RH9
RHEL 4 => FC3
RHEL 5 => FC6
Les bugs corrigés en phase de test de RHEL 5 sont repportés sur FC6 (et la branche développement) et aussi en upstream (Red Hat est très impliqué en upstream). Donc, ce n'est pas à sens unique. Ça profite à tout le monde.
Pourquoi RHEL 5 sort après FC6 tu vas demander. Excellente question.
FC6 n'a pas de partenaire. Pour sortir elle n'a pas besoin d'attendre que Dell ait vérifié que FC6 marche sur ses bécanes, elle n'a pas besoin d'attendre la certification d'Oracle, elle n'a pas besoin d'attendre que des formations pour l'administrer soient mise en place, etc...
FC6 n'est pas supportée (via de l'argent, un contrat entre un client et un fournisseur) et n'est pas destinée aux missions critiques où le moindre de bug est un scandale. Son contexte lui permet de sortir rapidement, ce qui fait le bonheur de beaucoup d'utilisateur qui veulent des trucs "flashy", et ce qui fait aussi le bonheur des développeurs qui peuvent se concentrer sur la version à venir au-lieu de buller car l'équipe de documentation n'a pas fini son taff (NB : la doc de RHEL est libre).
Tu trouves peut-être scandaleux le prix de RHEL ? RHEL étant un produit basé sur du libre et sur une distribution qui demande la contribution de la communauté.
Pas de problème, il y a Centos (et d'autres) pour toi : http://www.centos.org/
C'est un clone de RHEL (recompilation des sources de RHEL disponibles sur http://ftp.redhat.com/ et ses mirroirs), et je ne doute pas que Centos 5 va sortir au pire 2 semaines après la sortie de RHEL 5.
Donc Fedora (gratuite) donne RHEL (payante) qui donne Centos (gratuite). Pas de problème, la boucle est bouclée et l'argent de RHEL est utilisé pour développer Fedora (gratuite) et Centos (gratuite).
Notes que Red Hat ou Fedora n'a rien contre Centos. Par exemple le projet Extras Packages for Entreprise Linux : http://fedoraproject.org/wiki/Extras/Schedule/EnterpriseExtr(...)
Suis les liens et tu verras que tout est fait pour que ça marche aussi pour Centos et autres clones d'RHEL.
La communauté du libre a déjà assez à faire pour combattre les FUD de MS contre le logiciel libre. Voir par exemple : http://showusthecode.com/ .
Moi, et la communauté du libre, on se passerait volontier des FUD qui viennent de supporter du libre contre RHEL/Fedora qui est du logiciel libre. RHEL finance Fedora pour développer des technologies qu'on retrouve par exemple dans Mandriva (voir le buzz qu'il y avait pour AIGLX développé principalement par Fedora). RHEL finance aussi Centos qui est gratuit.
A bon entendeur...
PS : je le répète, je ne sais pas si le problème vient de CONFIG_DEBUG_SPINLOCK. J'ai dit qu'il est probablement que l'essai qu'a fait FreeBSD avec un 2.6.20.1 vanilla (sans patch Fedora) soit fait avec CONFIG_DEBUG_SPINLOCK. Mais j'en ai pas la preuve. Donc pour l'instant on ne sait pas que ça vient de CONFIG_DEBUG_SPINLOCK. J'ai seulement émis cette hypothèse.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Un benchmark FreeBSD 7 (CURRENT) et Fedora Core 6. Évalué à 10.
Il y a toujours du subjectif dans ces choix.
Pourquoi conserver la sortie du kernel (dmesg) si la distribution est sensée marcher sans accro ? D'ailleur cette sortie n'est pas affichée.
Pourquoi fournir SeLinux alors que les programmes livrés ne doivent pas avoir de trou de sécurité et marcher de façon sûr sans SeLinux ?
Pourquoi Fedora détecte les mauvais free (). exemple : "*** glibc detected *** gedit: free(): invalid pointer: 0x0858cb08 ***" ?
etc...
Pour spécifiquement CONFIG_DEBUG_SPINLOCK d'activité, je n'en sais rien.
Pour info, voilà les options de debug du dernier noyau FC6 :
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
Pour le noyau rawhide (développement) actuel :
CONFIG_DEBUG_DEVRES=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_RWSEMS=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_VM=y
On voit déjà que la version de développement à plus de debug. Je ne crois pas 2 second que les CONFIG_DEBUG* de FC6 soit uniquement pour débuggeur le noyau (sauf cas particulier) si c'est au prix d'une perte de performance significatif connue. Et ce pour plusieurs raisons :
- Fedora est développé de façon ouverte et ça gueulerait sévère sur les mailing list.
- Fedora n'a aucun intérêt à fournir un noyau lent, bien au contraire.
- Fedora a la branche développement pour ça et la branche testing pour les mises à jour.
Donc, pourquoi CONFIG_DEBUG_SPINLOCK ?
Voilà mon interprétation (je ne connais pas l'avis de Fedora).
Il va de soit que Fedora est aussi utilisé pour développer des applications. Il est dans les objectifs de Fedora d'être une plateforme pour le développement d'application. Le développement d'appli multi-thread est compliqué et se planter avec les futex est très courrant. Je crois qu'avec CONFIG_DEBUG_SPINLOCK le développeur sait s'il fait un unlock sur un mutex qui n'est pas locké ou sur un mutex créé depuis un autre processus mais dont on n'a pas mis le flag pour l'utiliser en inter-processus, etc... (Je dis peut-être des conneries ici, je n'ai pas vérifié dans le détail).
Génial tout ça !
Le problème est d'évaluer la contre partie. Pour une utilisation de mysql comme dans le bench de ce journal, la contre partie est intolérable (en imaginant que le problème vient de DEBUG_SPINLOCK, je n'en ai pas la preuve, je me suis hazardé dans une explication). Mais si la contre partie est en général une perte de performance de 0,01 %, et que DEBUG_SPINLOCK permet aussi aux développeurs d'appli de développer plus vite, alors DEBUG_SPINLOCK est (peut-être) justifié.
Pour les quelques cas où la contre partie est intolérable, il suffit de recompiler le noyau (les sources c'est aussi fait pour ça).
Notes que FC6 est sorti depuis plusieurs mois et c'est la première fois que CONFIG_DEBUG_SPINLOCK fait parlé de lui.
Un mot sur ce bench. Linux/Fedora a de moins bon résultat que FreeBSD pour un bench et pour un système à 8 cpus (seulement 1 à ce jour).
Et si le bench n'était pas représentatif ?
Et si le bench (ou mysql) avait un bug spécifique pour Linux qui n'impacte pas FreeBSD ? Ce n'est pas exactement le même code (il y a des #ifdef Linux etc..).
Se sont aussi des hypothèses à creuser. Quoique personnellement je ne chercherai pas là en premier. Même si le test est buggé il faut comprendre pourquoi Linux/Fedora s'écroule en monté en charge.
> Ne me dit pas que ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora ! Non ce serait trop machiavélique.....
Pour le troll fait en voulant nous faire croire que tu ne veux pas troller (alors que ce n'est pas la première fois que tu le fais...).
Les CONFIG_DEBUG de RHEL 4 (noyau 2.6.9, dernière mise à jour) :
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
Pour info, RHEL 5 en cours de développement utilise et utilisera un 2.6.18 (compatibilité binaire/source de RHEL oblige). FC6 a actuellement un 2.6.19 (le 2.6.20 ne devrait pas tarder) et la branche de développement de Fedora est en 2.6.20.
> ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora !
Comme tu pourrais dire ça pour Mandriva "classique" et Mandriva Corporate Server, etc...
Comme on pourrait dire qu'Ubuntu débuggue RHEL. Et oui, il y a des paquets dans Ubuntu qui seront dans RHEL. Tous les bug trouvés dans Ubuntu (idem pour Mandriva, Fedora, OpenSuSE, etc) profitent à RHEL (et aussi à Debian Etch :-))
Ta remarque est tout simplement ridicule, grotesque et il serait bon que t'arrêtes.
Et notes qu'en moyenne il n'y a qu'une Fedora sur 3 qui est utilisée comme base de RHEL :
RHEL 3 => RH9
RHEL 4 => FC3
RHEL 5 => FC6
Les bugs corrigés en phase de test de RHEL 5 sont repportés sur FC6 (et la branche développement) et aussi en upstream (Red Hat est très impliqué en upstream). Donc, ce n'est pas à sens unique. Ça profite à tout le monde.
Pourquoi RHEL 5 sort après FC6 tu vas demander. Excellente question.
FC6 n'a pas de partenaire. Pour sortir elle n'a pas besoin d'attendre que Dell ait vérifié que FC6 marche sur ses bécanes, elle n'a pas besoin d'attendre la certification d'Oracle, elle n'a pas besoin d'attendre que des formations pour l'administrer soient mise en place, etc...
FC6 n'est pas supportée (via de l'argent, un contrat entre un client et un fournisseur) et n'est pas destinée aux missions critiques où le moindre de bug est un scandale. Son contexte lui permet de sortir rapidement, ce qui fait le bonheur de beaucoup d'utilisateur qui veulent des trucs "flashy", et ce qui fait aussi le bonheur des développeurs qui peuvent se concentrer sur la version à venir au-lieu de buller car l'équipe de documentation n'a pas fini son taff (NB : la doc de RHEL est libre).
Tu trouves peut-être scandaleux le prix de RHEL ? RHEL étant un produit basé sur du libre et sur une distribution qui demande la contribution de la communauté.
Pas de problème, il y a Centos (et d'autres) pour toi : http://www.centos.org/
C'est un clone de RHEL (recompilation des sources de RHEL disponibles sur http://ftp.redhat.com/ et ses mirroirs), et je ne doute pas que Centos 5 va sortir au pire 2 semaines après la sortie de RHEL 5.
Donc Fedora (gratuite) donne RHEL (payante) qui donne Centos (gratuite). Pas de problème, la boucle est bouclée et l'argent de RHEL est utilisé pour développer Fedora (gratuite) et Centos (gratuite).
Notes que Red Hat ou Fedora n'a rien contre Centos. Par exemple le projet Extras Packages for Entreprise Linux :
http://fedoraproject.org/wiki/Extras/Schedule/EnterpriseExtr(...)
Suis les liens et tu verras que tout est fait pour que ça marche aussi pour Centos et autres clones d'RHEL.
La communauté du libre a déjà assez à faire pour combattre les FUD de MS contre le logiciel libre. Voir par exemple : http://showusthecode.com/ .
Moi, et la communauté du libre, on se passerait volontier des FUD qui viennent de supporter du libre contre RHEL/Fedora qui est du logiciel libre. RHEL finance Fedora pour développer des technologies qu'on retrouve par exemple dans Mandriva (voir le buzz qu'il y avait pour AIGLX développé principalement par Fedora). RHEL finance aussi Centos qui est gratuit.
A bon entendeur...
PS : je le répète, je ne sais pas si le problème vient de CONFIG_DEBUG_SPINLOCK. J'ai dit qu'il est probablement que l'essai qu'a fait FreeBSD avec un 2.6.20.1 vanilla (sans patch Fedora) soit fait avec CONFIG_DEBUG_SPINLOCK. Mais j'en ai pas la preuve. Donc pour l'instant on ne sait pas que ça vient de CONFIG_DEBUG_SPINLOCK. J'ai seulement émis cette hypothèse.