Reprise du message précédent :

il était sous entendu la doc/possibilité de nfs

 
non, je n'ai pas lu
parce contre y-a le sfs qui peut être bien aussi

non, et la 2.6.3-13mdk non plus, c'est pour ça que j'ai précisé la version complète

 
Use the force, read the source code

dites ...
 
Je suis en kernel 2.6 depuis qq mois.
J'aurais qq questions.
C'est sur la gestion des modules. Je voudrais savoir :
1 - Comment on force un module au démarrage  
(l'équivalent de /etc/modules sous le 2.4)
2 - Comment on ajoute un module au démarrage en lui passant des paramètres.  
(l'equivalent de /etc/modutils et update-modules sous le 2.4)
 
en fait,je voudrais au moins savoir comment on ajoute un module au démarrage tout sumplement.
Je trouve pas de doc claire sur le net la dessus. Si vous avez des réponses ou des liens, ce serait sympa.  
merci.

/etc/modules => /etc/modprobe.preload
/etc/modules.conf => /etc/modprobre.conf

que pensez vous de ce que dit con kolivas ici :  

 
?

J'ai activé le preempt et j'ai encore vu aucun pb

Perso je le vire à chaque fois maintenant (depuis 2.6.5) sur les configs à base d'AMD, j'en avais marre des erreurs preempt avec les périphs USB dans les logs et j'avais des gros locks. Sans ça fonctionne bien mieux je trouve, par contre sur mon celeron ça semble mieux tourner avec
 
Faut tester avec et sans, pas évident de prédire si sur telle machine ce sera plus efficace avec ou sans

comment ça marche au juste ? qq'un a une explication un peu plus technique que le sampiternel "ça sert à ce que ça soit plus réactif" ?  

une précision sur les scheduler :
j'ai cru comprendre que cfq, anticipatory sont des I/O scheduler et que staircase, O(1) sont des process scheduler. Et que par défaut sur un 2.6.7 vanilla c'est anticipatory+O(1) qui est utilisé. Pour utiliser, cfq il suffit de mettre "elevator=cfq" dans lilo, et pour staircase faut patcher et c'est auto.
 
J'ai bon ? Vous utilisez quoi comme I/O et process sched ?

 
pour le i/o j'utilise le cfq qui est le seul avec lequel je suis sur que la music ne sautera pas
pour le process sched, je laisse celui par défaut parce que les alternatifs apportent rarement des améliorations significatives (ça se voit pas à vue d'oeil, pas sur un desktop en tout cas), alors que les regressions se voit bien elle (un coup ça rame tu sais pas pourquoi, la music saute, etc ...) : donc celui par défaut a des perf régulieres et c'est plus agréable ainsi

donc a priori ce que j'ai dit n'est pas faux, c'est + clair dans ma tête.    
Pour ma part j'utilise cfq + O(1) aussi.

O(1) n'est pas un logiciel, c'est la complexité de l'algorithme : il donne une réponse dans le même laps de temps quel que soit la taille des données en entrée.

Oui mais on utilise le terme O(1) pour qualifier le nouvel algo de préemption qui était anciennement en O(n)

Quand un processus est actif (il dispose du CPU pou rexécuter son code), et qu'il se fait piquer le CPU, suite à plusieurs raisons (quantum de temps d'utilisation du CPU terminé, interruption, etc.), on dit qu'il se fait préempter.
 
On qualifie les système capable de prendre le CPU à un processus de système préemptif, tandis qu'un système qui peut se faire piquer le CPU est qualifié de préemptible.
 
Dans notre cas, on parle bien de noyau préemptible : les systèmes préemptifs existent depuis longtemps ! (depuis le début de Linux, Win95, et globalement, la plupart des systèmes multitâches)
 
Avec les kernels 2.4 et 2.6 sans l'option preempt, le kernel ne peut pas se faire préempter. Je m'explique :
1) tu as un processus qui tourne sur le CPU
2) hop, ya une interruption qui arrive (quelle qu'elle soit, du genre, quantum de temps alloué au processus qui est écoulé), et c'est le code du kernel qui prends le controle
3) si ya une interruption qui arrive à ce moment là, et bien elle peut aller se faire voir ailleurs, le kernel l'ignore, puisqu'il ne peut pas être interrompu
4) le kernel file le CPU à un autre processus
5) ce processus peut se faire à nouveau préempter quand une interruption arrive
 
Maintenant, avec le noyau 2.6, option preempt activé, pendant l'étape 3, le kernel peut se faire préempter, pour filer le CPU à un processus qui traitera l'interruption. Donc, en théorie, on dit qu'on a un système plus réactif, puisque plus à même de pouvoir traiter les évenements qui se passe, à n'importe quel moment...
 
Voilà pour l'explication, il doit surement avoir des trucs pas super juste (ça fait 2 mois que je suis plus en cours ), mais je pense que le principe est là
 
Sinon, pour le fait que l'effet soit pas plus marqué que ça, comparé à un kernel 2.4, ça peut (je pense) s'explique à cause que le temps alloué à chaque processus a diminuer dans le 2.6. Il me semble qu'on est passé de 25 à 15 (aucune idée des unités ). Du coup, le système peut sembler plus réactif, même sans le preempt ....
 
Edit : ajout de la distinction préemptif/préemptible

aaaah ok, merci pour l'explication
interrompre le kernel, 't1, y-a interet que ça soit au point leur truc quand même
j'imagine qu'on peut pas interrompre tout quand même si ? genre le scheduler ? je doute qu'il puisse être interrompu en plein milieu de son traitement lui, sinon ça fouterait un beau merdier je pense ...
 
sinon pour les unités on s'en fout, du moment qu'on a le rapport entre avant et après
j'essaierais peut-être sans preempt tout à l'heure pour voir
d'autant que j'ai une merde "blabla while atomic" quand j'utilise alsamixer, et ça peut peut-être venir de ça, donc ça me permettra de vérifier

http://www.kernel.org/diff/diffvie [...] .bz2;z=121
je parie que c'est de sa faute à lui !  

http://www.linux-france.org/prj/ja [...] mptif.html
 
Je pense pas que se soit le kernel qui peut se faire "preempter" mais une tache X
 
Genre:
 
une tache à 200 ms pour besogner mais interruption donc on l'arrete à 133 ms et on passe la main à l'autre
 
un systeme non preemptif finirait la tache de 200 ms et passerait la main à l'autre

En fait, je me suis planté un peu, la plupart de systèmes d'exploitation actuel sont qualifiés de préemptif, ce qui veut dire qu'ils sont capable d'interrompre un certain processus à un moment donné.
 
Il ne faut pas confondre avec un processus (ou le kernel dans ce cas) préemptible, qui peut être interrompu.
 
Dans le cas du noyau de Linux, celui-ci est préemptible (Preemptible Kernel dans le menuconfig du 2.6.7), donc, c'est bien un noyau qui se peut se faire préempter ...
 
Note : préemptible, c'est surement pas du français
 
Edit: j'ai corrigé le post au dessus avec ces infos. Apparement, on confond souvent les deux d'ailleurs ...

multani-1 > ça remet pas en cause ton explication du dessus toute façon ? faut juste remplacer preemptif par preemptible ?
le noyau peut être interrompu c'est bien ça ?
parce que toute façon pour les processus, on a pas attendu le 2.6 pour le faire
même windows sait faire ça

Ouais, c'était pas faux, mais c'était pas super précis non plus
 
Bon, pour vérifier, j'ai quand même fait un tour sur le net voir ce qu'on disait la dessus : sur plein de site, on parle bien de la nouvelle feature qui tue, le kernel "préemptif" ...
Du coup, ça peut vraiment porté à confusion ...
En même temps :

quoted du menuconfig : CONFIG_PREEMPT:   This option reduces the latency of the kernel when reacting to real-time or interactive events by allowing a low priority process to be preempted even if it is in kernel mode executing a system call. This allows applications to run more reliably even when the system is under load.     Say Y here if you are building a kernel for a desktop, embedded or real-time system. Say N if you are unsure.

 
qu'on peut traduire par :
"[...] un processus de basse priorité peut être préempté même si il est en train d'éxécuter un appel système un mode noyau. [...]"
 
D'après ce que j'ai lu, le kernel disposerait maintenant de différents points où il a la possibilité de se faire préempter (les "preemption points" ). Quand il arrive à ces points, il fait des tests pour savoir si il doit passer le CPU à un autre processus. Si c'est le cas, il interrompt l'appel système en cours (et donc, le processus qui a fait l'appel système), pour donner la main au processus qui en fait la demande.

Salut,
 
j'avais lu je sais plus où un test qui comparait le kernel préemptible à la diminution de la latence (le fameux patch low-latency) et le verdict était sans appel : le low-latency était vraiment beaucoup + efficace pour améliorer la réactivité que le kernel préemptible. Et en mettant les 2 ensemble, on ne voyait quasiment que l'effet du low-latency.
 
Et comme le low-latency a été intégré au 2.6, je pense qu'il y a un rapport avec tout ce qui vient d'être dit

 
il fait quoi le low latency ? lui il est bien actif par défaut non ? pas d'option ?

verdict : je sais pas trop quoi faire comme test pour voir si ça va plus vite (pas facile de mesurer la réactivité), mais à vue d'oeil je vois pas trop de changement sans le preempt
et mon pb avec alsamixer a bien disparu

 
je pense que c'est lié à ce qu'a dit multani-1 à propos du temps alloué à chaque processus

 
 
après une série d'échecs plus ou moins cuisants dans la configuration de mon tout nouveau noyeau 2.6.7 (je suis sous linux depuis avant-hier seulement), j'ai enfin réussi à tout faire fonctionner à peu près correctement.
Tout ? Non, car la carte réseau résiste encore et toujours et je ne sais pas trop ce qu'il faut mettre en option pour qu'elle fonctionne.  
 
Pour info c'est une carte PCI 10M (avec base T) de marque inconnue au bataillon (Windows la détecte comme une Realtek).
 
Voilà, si vous pouviez m'indiquer les options à mettre dans le bouzin ça m'aiderai pas mal  

regarde exactement ce que c'est comme chipset realtek.

avec le kernel bf24, qui détecte la carte, j'obtiens ça dans syslog
 

donc c'est un rtl8029, module ne2k-pci

ok, je vais tenter ça.
 
Merci

http://forum.hardware.fr/hardwaref [...] 5751-1.htm

ça marche impec'
 
Merci

Salut
Je n'ai pas de linux sous la main pour tester, est ce que quelqu'un peut me dire si quand on fais un make_modules_install ça supprime les modules qui étaient là avant ou si il faut les supprimer manuellement dans /lib/modules ?

En 3 mois j'ai planté 3 fois mon kernel, enfin d'un coup, plus rien ne bouge, le bouton power tu pc qui éteint le pc normalement ne va plus non plus. Ca arrive quand je change de chaine de la télé. C'est triste

 
c'est pas très propre de réinstaller par dessus, il vaut mieux booter sur un autre noyau et supprimer le répertoire des modules, le noyau (+ le system.map et l'initrd s'ils ont été placés), ou alors éditer le Makefile en rajoutant un paramètre à "EXTRAVERSION =" et lancer la compilation (ce que font les distro généralement en apposant "custom" )

 
Argl, tout ça...

Une question liée au noyau 2.6 :
Y'a-t-il un programme qui permette de passer de reiser3.6 à reiser4 sans perte de données ?

GNU fileutils
(cp)

SANS bouger les données bien sur.

j'ai un pb. avec MDK-10-off et son noyau 2.6.3-x-mdk
 
mon serveur DNS bind n'arrive pas a lancer named sur un noyau 2.6.3-x alors que sur un noyau 2.4.x-mdk ca marche . En faite , il ne trouve pas l'user named , qui est bien renseigné dans /etc/shadow et /etc/passwd
 
j'ai essayé sur plusieurs machine sur un noyau 2.6-mdk et ca marche pas  
 
quelqu'un a une idée ?