Reprise du message précédent :

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

Ma première distrib

 
No comment

Bah quitte à la rebooter, t'aurais quand meme pu la mettre à jour

t'es ouf ou quoi ? quand elle aura 10 ans c'est champagne

j'ai trouvé plus vieux \o/

(la machine en question supporte une base oracle)

Revenons au sujet. Con Kolivas a présenté un nouvel ordonnaceur de processus (CPU scheduler) qui semble un peu plus efficace que l'existant et si je lis bien, limiterait la latence :
http://lwn.net/Articles/224865/
 

Bonjour, je me pose une question peut-etre ridicule mais bon je prends le "risque" de la poser quand même  

Voila, lorsque je rentre dans "Processor type and features  --->" "Processor family (AMD-Opteron/Athlon64)  ---"

je n'ai plus que 4 choix de processeurs, je ne me souviens plus quand cette particularité est arrivé,
1-) est-ce lié a la version du noyau, a la version de ma Gentoo (amd64) ou autre chose  

2-) Comment make menuconfig "détecte" qu'il faut obligatoirement me proposer un processeur 64 bits et pas un autre  

voila mes choix dans la dite section, j'espère ne pas paraitre ridicule avec ça mais bon :

Quelle version/paquet des sources tu utilises ?

Tu veux parler des sources du noyau ?

c'est le 2.6.21-rc3 de kernel.org  

Edit: je l'ai eu là exactement:
http://www.kernel.org/pub/linux/ke [...] c3.tar.bz2

> trouble_fete
 
C'est peut-être bien parce que tu tentes de compiler les sources à partir d'un environnement 64 bits, et donc implicitement à partir d'une architecture 64 bits (d'où les processeurs listés).
 
Tu vas devoir recourir au cross-compiling (ou compilation croisée) si tu veux obtenir une version de noyau compilé pour une autre architecture que la tienne. Pour cela, par exemple pour une version 32 bits, il va te falloir recréer un environnement 32 bits à partir duquel tu vas compiler les sources, pour ce type d'opération on utilise généralement un chroot, mais au cas où tu n'es pas familier avec ce type d'opération, il doit être possible de le faire également à partir d'un live-CD suffisamment complet ou encore à partir d'un système virtualisé (genre Qemu ou mieux, Xen).

Salut THRAK merci pour l'explication, je compte garder mon noyau comme ça par contre, ma question c'était juste pour savoir le pourquoi du comment comme on dit (curiosité quoi )

Interressant cette discussion ordonnanceur préemp.
 
Ca me donnerait presque envie de recompiler mon kernel debian avec en préemptif mais je reste toujours dubitatif sur le gain de performance...
 
Des chiffres ?

je doute que tu gagnes réellement en terme de performance brute, tu gagnes surtout en réactivité, aucune tâche ne pouvant bloquer.

Ha, tu n'as pas utilisé emerge pour les dl et les installer. ok.

Je pense pas, vu que, je suis en archi AMD64, et qd je configure mon noyau, j'ai le choix pour tous les types de procs.
 
Par contre, ce sont les sources patchés Gentoo, ramenés/installés par le package manager.
Est ce que la différence vient de là ?  je ne sais pas ...
 

 
 
bon jsuis pas en forme, jvais ptet pu poster aujourd'hui, jme demande si j'ai pas du diabete d'ailleurs  

tu bois beaucoup (vraiment beaucoup, tout le temps soif), tu vas souvent au toilettes ?

À la base j'ai créé ce topic avec l'intention de faire des benchs -et c'est toujours le cas- (j'ai une machine dédiée pour ça) mais jusqu'ici je n'ai toujours pas trouvé le temps
 
Le problème tient à la fois au fait qu'il faudrait que je créé quelques scripts sur-mesure pour que ce soit représentatif (et je ne m'y suis pas encore plus penché que ça), et ensuite que je fasse une comparaison basée sur un triple critère : preempt / scheduler / filesystem ce qui fait tout de même pas mal de combinaisons à tester et donc de temps à passer là-dessus.
 
Probablement que si d'ici là je ne l'ai toujours pas fait, je verrais cet été ou je devrais probablement avoir un peu plus de temps pour cela.    
 
 
 

   
Assurément, cela se ressent surtout dans des environnements à forte charge où certaines applications nécessitent des temps de latences extrêmement bas (audio ou video processing). Enfin s'il y a un gain, même minime et difficile à jauger comme ça, d'une façon ou d'une autre il doit toujours y avoir moyen de le mesurer.
 
 
PS:
Trop soif c'est symptomatique du diabète ? Moi c'est l'inverse...  je doute que ce soit forcément mieux aussi...  

ce sont les premiers grands symptômes : polydipsie (soif inextinguible), polyurie (on pisse tout le temps) et polyphagie (on a tout le temps faim).

M'enfin généralement, le diagnostic se fait sur la glycémie à jeun ou après une épreuve de HGPO.

http://www.phoronix.com/scan.php?p [...] =651&num=1
 
Un mini benchmark sur l'option CONFIG_NO_HZ et les tickless kernels.
On a pas l'air d'y gagner beaucoup

j'ai vachement soif en effet !! et forcément assez souvent aux toilettes bien ke g une grosse vessie...
Le gros prob c quand comme tt a l'heure je mange pas mal de trucs sucrés, jme sens TRES faible (physiquement notamment)...et petits problèmes de vues a ce moment là aussi...
:s
 
 
Edit: jcrois qu'il va falloir que j'en parle au medecin quand même un de ces 4...
 
Edit2: par contre quand je sature niveau sucre (bouffer trop de "cochonneries" ) je n'ai non seulement plus faim, mais même des nausées, en plus d'etre faible au point de m'assoupir...

Sur le conseil de mikala, petite mise à jour du topic.    
 
Une synthèse des principaux points abordés figure désormais en première page (second post).

\o/

j'ai utilisé le patch CK, mais je ne trouve pas comment activer le SD, si quelqu'un sait ca m'interesse

pour le:

• Generic X86 Support

étant donné que j'ai un AMD athlon xp 2200+ (oc 2800+) si je le desactive je gagne en perf ou pas ?
 
 
 [ ] Paravirtualization support (EXPERIMENTAL) <<< quézako ?
 
sinon depuis que je suis passé en 2.6.21 mon kernel met 3 plombes a determiner le temp :s y a il un moyen de revenir en arriere ?
 

paravirt_ops.
 
Interessant si tu utilises KVM ou vmware.

je n'arrive pas a lancer le module de vmware

edit: si comme moi vous utilisez les fglrx de chez ati : il ne faut pas cocher ca, ca empeche aux drivers de compiler je vins d'avoir le probleme du coup je recompile (encore)

Si tu as spécifié ton type de processeur dans Processor Family, alors l'option Generic x86 Support ne sert strictement à rien. En fait, elle permet de bénéficier d'un minimum d'optimisation pour les processeurs de classe x86 dont on ne connait pas précisément le modèle ; elle n'a donc pas d'intérêt et peut être désactivée si tu connais ton processeur et que tu as activé les optimisations qui lui sont spécifiques.
 
Si l'on parle de tuning/d'optimisation du noyau, alors on dira que toute option inutile devrait de préférence être désactivée.
 
 
 
Sinon l'option Paravirtualization Support n'a d'intérêt que sur des machines disposant d'un processeur doté de fonctions de paravirtualisation, et censées gérer des systèmes s'exécutant spécifiquement au sein de machines virtuelles. Autrement, l'exécution du noyau peut être plus lente, il est donc conseillé de désactiver cette option dans la plupart des cas.

Je ne suis pas certain de ca

Dans la mesure où c'est avant tout orienté vers KVM, et que ce dernier tire seulement parti des processeurs Intel avec extensions VT ou AMD avec extensions SVM, c'est plutôt le cas.  

Oui mais non, c'est une interface commune entre KVM, VMware et bientot (2.6.22 si tout va bien) Xen.
Qui eux supportent la virtualisation hard et non-hard.
D'ailleurs quand y a pas de support hard, on parle de para-virtualisation, donc paravit_ops => pas forcement hardware.
 
Enfin il me semble

Quelques petites informations sur la future mandriva 2008.0
les kernels mandriva seront basés sur le 2.6.22 et disposeront de plusieurs versions:
laptop,desktop,server.
 
on utilise désormais par défaut CFS pour le cpu scheduler et cfq pour le i/o scheduler
ils sont compilés avec les options  HZ_1000 et volontary_preempt pour les versions desktop/laptop.
la version laptop utilise de surcroit d'autres optimisations pour la batterie.
 
 
 
Il existe également des versions  -xen , -mm et vserver
 
(histoire de maintenir vivant le topic )

Puisqu'on parle de CFS, un lien vers un outil permettant un "Completely Unfair Scheduling" :
http://kerneltrap.org/Linux/DeskOp [...] Scheduling

Vu que je compile moi-même mes kernailles, je ne sais même pas ce que Debian met par défaut comme options en ce moment (avec les versions récentes de Sid).
 
 
Sinon niveau config c'est à peu de chose près ce que j'utilise chez moi (portable sous Sid) :
 
  -> version du noyau : 2.6.22.5
  -> pour l'I/O scheduler : CFQ
  -> pour la latence : CONFIG_PREEMPT (low-latency desktop), CONFIG_HZ=1000
  -> pour l'énergie : CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS, CONFIG_HPET_TIMER,  
 
 
En outre je remplace l'utilisation de CONFIG_CPU_FREQ_GOV_ONDEMAND (module cpufreq_ondemand) par :
  -> CONFIG_CPU_FREQ_GOV_CONSERVATIVE (module cpufreq_conservative)
 
Après powersave (fréquence bloquée au minimum), ce gouverneur cpufreq est le plus économe en batterie ; il fonctionne en adaptant dynamiquement la fréquence du processeur, de la même manière que ondemand, mais à la différence de ce dernier les changements de fréquences sont moins brutaux et on passe par palier d'une fréquence à une autre en fonction de la charge (le cpu doit supporter plusieurs fréquences, cela va de soi).
 
 
J'ai également eu l'occasion d'un petit peu tester la nouvelle stack firewire, très prometteuse ; voici les options et les modules correspondants :
 
  -> CONFIG_FIREWIRE (module firewire_core)
  -> CONFIG_FIREWIRE_OHCI (module firewire_ohci)
  -> CONFIG_FIREWIRE_SBP2 (module firewire_sbp2)
 
 
Un tranfert de 20,1 GiB depuis le disque de mon portable vers un disque dur externe firewire (Iomega / Seagate ST3300822A) met un peu moins de 5m 40s ; soit un taux avoisinant les 60 MiB/s, plus que correct donc.
 
 
Pour info un extrait des logs de la nouvelle stack lors de la connexion et du montage d'un volume

UP !    
 
 
 
Lorsqu'on parle de performance pour un système d'exploitation, l'un des critères les plus important est assurément la réactivité de ce dernier.
 
 
En fonction de la charge à laquelle est soumis l'OS, le temps de réponse des applications qui s'exécutent peut grandement varier (allant du très court au très long) avec un impact direct sur le fonctionnement et, de ce fait, des conséquences parfois critiques au niveau du confort d'utilisation, aussi bien dans un environnement desktop que serveur.
 
Profiter d'un système offrant une réactivité maximale est souvent, et c'est aisément compréhensible, une des principales préoccupation en matière d'optimisation. Cependant, ce processus est loin d'être simple à mettre en oeuvre ne serait-ce parce qu'il nécessite d'analyser en profondeur l'activité du système, plus exactement en mesurant de façon précise (et non subjective) les temps de latence des nombreux processus traités par le noyau.
 
 
Heureusement, pour Linux -cas qui nous intéresse plus spécialement ici- un outil spécialement développé dans ce but ravira les développeurs noyau comme les utilisateurs en perpétuelle quête d'efficacité :
 
   ---> LatencyTOP
 
 
Initié par Intel et plus particulièrement le développeur Arjan Van De Ven (auteur de l'outil PowerTOP), LatencyTOP se présente sous la forme de patchs pour le noyau (qui seront certainement intégrés à terme dans la branche principale en tant qu'option de debug) et d'un outil en espace utilisateur. Voilà pour l'essentiel, n'hésitez pas à consulter le site ci-dessus pour plus d'infos, et à tester tout ça bien sûr.    
 
 
Vraiment intéressant de mon point de vue   , gageons que cet outil s'avérera des plus utiles tant pour l'amélioration des futures versions du noyau Linux en terme de réactivité, que pour la résolution de problèmes de latence -ponctuels ou récurrents- chez les utilisateurs motivés par ce genre de joujou.
 

drapal!

 
le uptime est remis à zéro à chaque reboot hein

il va falloir faire attention désormais à la qualité de tes posts car remonter un topic pour enfoncer une porte ouverte en étant totalement a coté du sujet n'est même plus risible.
ceci est évidemment a prendre comme un unique avertissement pour l'ensemble de tes posts sur la section.

Tu penses que le "drapal" ou le "up" posté juste avant constitue plus un message de qualité pour le forum ?

Il n'y a pas eu d'alerte modération, ton message ne semble donc avoir qu'un but rétorsif non fondé et de défoulement, vu qu'aucune alerte modération ne t'as sans doute amené jusqu'ici.
Je répond ici, et non en pv pour que tout un chacun puisse constater le décalage entre le message posté (sauf si tu l'effaces) et ta réaction.
D'autant plus qu'un avertissement pour l'ensemble de mes posts ? Nan mais je rêve ou quoi tu as donc juger 100% de mes posts comme étant d'une qualité proche de zéro ? Il n'y a donc aucun message d'aide ou de question utiles de ma part ?

Et je ne vois pas non plus en quoi mon précédent message est HS, en tout cas pas plus qu'un "up" ou un "drapal" très courants sur ce forum.
Je ne vois pas non plus en quoi remonter un sujet unique est un mal.
Si oui indique moi la règle du forum l'indiquant.

Comme tu te couvres en n'accordant aucun droit de réponse à l'avance, je préfère encore mettre les choses au point tout de suite en prenant pour témoin ce que tu considères comme n'étant pas un post de qualité par rapport à tes standards, et risquer une sanction. Vu que c'est pas la première fois que tu tombes sur les gens pour les faire marcher droit sans spécialement de raison.

Mon but n'est absolument pas de faire preuve d'outrecuidance ou de provoquer la modération, j'ai autre chose à faire, mais j'ai clairement pas envie non plus de poster sous une chappe rétorsive et avec une matraque brandie sur la tête à chaque messages.

Si l'ensemble des mes messages est trollesque, alors étaille bien tes arguments car à part quelques dérives hs potentielles sur le sujet ubuntu je ne vois pas de quoi tu parles.

le post précédent datant de plus d'un an n'est pas plus valide que le tiens encore le contenu est moins léger et annoncer clairement la couleur....
A noter qu'il existe tout de même l'option favori pour éviter d'y coller un drapeau de présence...

Au cas où tu ne serais pas au courant il existe une interface de modération permettant de parcourir l'ensemble des posts effectués sur la catégorie placée sous la responsabilité d'un modérateur.
Il n'y a donc nul  besoin d'utiliser la fonction d'alerte de modération ne t'en déplaise. Accessoirement la majorité des activités de modération ne s'effectue pas suite a une  délation...
Si je voulais uniquement me défouler j'aurais simplement pu opter pour la fonction poster en modérateur anonyme...

Quel décalage ?
c'est un unique avertissement point pour t'éviter de retomber dans de tels travers d'autant plus si l'on suit l'évolution de tes posts sur cette section, ne t'en déplaise.
Accessoirement que tu souhaites répondre en publique ne pose aucun souci, tu peux en revanche opter pour le sujet dédié au discussions avec la modération qui est d'accès publique.
 

la formulation que j'ai utilisé est  
« faire attention désormais a la qualité de tes posts »
il faut donc entendre que les prochains posts doivent être un peu plus fourni en qualité que de simple post destinés a enfoncer des portes ouvertes...

dans ce cas un simple « drapal »  (encore que je trouve la chose inutile lorsqu'il existe l'option favori) aurait été nettement plus approprié que ta phrase consistant a vouloir enfoncer des portes ouvertes...

Il n'y a heureusement pas des règles couvrant l'ensemble des situations...
 

je n'ai une fois de plus pas précisé l'ensemble de tes posts, je ne parle que de tes posts futurrs....
Après si tu y a pris la mouche sur l'ensemble de tes posts je n'y peux rien.
Le reste de la conversation se tiendra donc sur le topic dédié aux discussions avec la modération.