Nouvelles options du kernel 2.4.20 ? - Installation - Linux et OS Alternatifs
Marsh Posté le 04-10-2002 à 00:13:07
ça aurait été avec plaisir, mais là franchement j'en sais rien
Marsh Posté le 04-10-2002 à 09:55:27
hummm... tu est sur que tout ca ne viens pas d'une mauvaise conception applicative? parcequ'autants de process lourds est des fois un problème de conception...
Marsh Posté le 04-10-2002 à 11:13:39
PinG : Non je ne pense pas franchement, de ce côté là ça fait un moment que c'est optimisé au maximum
Marsh Posté le 04-10-2002 à 11:20:23
La serie des 2.5 te tentent pas ?
Il y a une option low latency du kernel qui fait des miracles
Marsh Posté le 04-10-2002 à 11:22:09
le problème avec les 2.5.xx c'est que le module Nvidia_kernel est super galère à compiler et que Warko pourra plus jouer à Quake3 sur le serveur
Marsh Posté le 04-10-2002 à 12:14:10
911GT3 a écrit a écrit : le problème avec les 2.5.xx c'est que le module Nvidia_kernel est super galère à compiler et que Warko pourra plus jouer à Quake3 sur le serveur |
Marsh Posté le 04-10-2002 à 12:17:25
911GT3 a écrit a écrit : le problème avec les 2.5.xx c'est que le module Nvidia_kernel est super galère à compiler et que Warko pourra plus jouer à Quake3 sur le serveur |
Marsh Posté le 04-10-2002 à 12:18:14
mean a écrit a écrit : La serie des 2.5 te tentent pas ? Il y a une option low latency du kernel qui fait des miracles |
Je veux pas un kernel pas stable ( déjà qu'avec les stable parfois... )
Le Low Latency je le mets en patch sur le 2.4 déjà
Au départ ma question était surtout d'avoir des informations sur les options que j'ai cité quoi, je voudrais bien savoir ce que ça apporte... ( curiosité autant qu'intérêt )
Le reste ça fait déjà un moment que je lis des choses dessus, mais ça je trouve rien
Marsh Posté le 04-10-2002 à 12:18:56
911GT3 a écrit a écrit : le problème avec les 2.5.xx c'est que le module Nvidia_kernel est super galère à compiler et que Warko pourra plus jouer à Quake3 sur le serveur |
Marsh Posté le 04-10-2002 à 12:28:15
ben tu lance gkrellm et tu regarde ce qui pompe le plus sur le serveur, la charge system ou la charge user, et pis tu teste en conséquence
après tout c un serveur de test ici
Marsh Posté le 04-10-2002 à 13:17:59
C'est 50/50, on peut le voir avec top aussi, ça évite d'avoir à installer X et GTK pour rediriger une fenetre sur mon petit ADSL hein
Mais je le répéte, je voudrais SAVOIR ce que donnent ces options, c'est un plus après si je peux gagner quelque chose sur le serveur, mais si c'est juste me donner des choses connues qui ne sont pas en rapport direct avec ces options, ça va pas trop m'apprendre grand chose
Marsh Posté le 04-10-2002 à 14:03:31
Il est comment le 2.4.20 sly ca fait longtemps que je suis plus sous linux ?
Marsh Posté le 04-10-2002 à 14:09:13
Je l'ai essayé 24 heures chez moi, rien de spécial à signaler, il me semblait pas mal speeder et apporter des choses intéressantes. Par contre je l'ai mis sur le serveur du forum pour voir, comme en plus il est censé être plus performant avec au niveau du FS, mais en 1 heure il a crashé net ( freeze )
Alors je crois que j'émettrais des réserves sur sa fiabilité
Marsh Posté le 04-10-2002 à 14:33:47
Crystalizer a écrit a écrit : tu as du pe oublier des options ... |
ouaip, genre activer le
Kernel stability module |
et désactiver le
random 'ala' w95 bugs, crashs, BSOD, segfaults, freeze |
(attention si vous utilisez une mdk, désactivez le premier et activez le second pour vous retrouver dans un environnement mdk-complient)
Marsh Posté le 04-10-2002 à 14:43:20
Crystalizer a écrit a écrit : tu as du pe oublier des options ... |
genre ? Je connais bien les options dont j'ai besoin pour cette machine et je n'ai rien ajouté de superflu, je vois mal une option manquante provoquer un freeze direct au bout d'une heure alors que tout marchait très bien jusque là...
PinG : Oui j'avais pourtant bien désactivé le "joce mode"
Marsh Posté le 04-10-2002 à 15:06:23
Sly Angel a écrit a écrit : PinG : Oui j'avais pourtant bien désactivé le "joce mode" |
qui devrait d'ailleurs être inclu dans tous les kernels
un peu comme le mode tutu...
Marsh Posté le 04-10-2002 à 15:12:38
Sly Angel a écrit a écrit : genre ? Je connais bien les options dont j'ai besoin pour cette machine et je n'ai rien ajouté de superflu, je vois mal une option manquante provoquer un freeze direct au bout d'une heure alors que tout marchait très bien jusque là... PinG : Oui j'avais pourtant bien désactivé le "joce mode" |
houlà... le joce mode, c'est pas ce module qui fait :
Code :
|
Marsh Posté le 04-10-2002 à 15:32:24
PS : si vous voulez tester :
# vi joce.c |
Code :
|
# gcc joce.c -o joce |
PS1 : si vous testez, gardez un 'killall joce' sous la main
PS2 : ne si vous testez en root, sauvez à l'avance tous vos documents
Marsh Posté le 04-10-2002 à 15:47:41
dofor a écrit a écrit : je sais pas jle sens mal là |
ca ne touche pas au FS, donc pas de crainte, mais il est possible que ca mette moins d'une minute avant de planter si ta bécanne est pas configurée proprement...
Marsh Posté le 04-10-2002 à 15:47:57
PinG a écrit a écrit : ca ne touche pas au FS, donc pas de crainte, mais il est possible que ca mette moins d'une minute avant de planter si ta bécanne est pas configurée proprement... |
je parle du kernel hein
Marsh Posté le 04-10-2002 à 15:49:28
bon bon bon... j'aime bien les expériences
ça fait quoi exactement?
Marsh Posté le 04-10-2002 à 15:49:45
dofor a écrit a écrit : je sais pas jle sens mal là |
ne JAMAIS suivre Ping dans un de ses post si il contient
- #include<sys/*> dans un code C
- /dev/* dans un script
Marsh Posté le 04-10-2002 à 15:51:03
sh-2.05a$ gcc joce.c -o joce
joce.c:1: erreur d'analyse syntaxique avant le jeton « < »
Dans le fichier inclus à partir de /usr/include/bits/types.h:143,
à partir de /usr/include/sys/types.h:30,
à partir de joce.c:2:
/usr/include/bits/pthreadtypes.h:48: erreur d'analyse syntaxique avant « size_t
»
/usr/include/bits/pthreadtypes.h:51: erreur d'analyse syntaxique avant « __stack
size »
Dans le fichier inclus à partir de joce.c:3:
/usr/include/unistd.h:310: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:313: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:423: erreur d'analyse syntaxique avant « size_t »
Dans le fichier inclus à partir de joce.c:3:
/usr/include/unistd.h:513: erreur d'analyse syntaxique avant « confstr »
/usr/include/unistd.h:513: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:664: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:689: erreur d'analyse syntaxique avant « size_t »
Dans le fichier inclus à partir de joce.c:3:
/usr/include/unistd.h:734: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:741: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:751: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:752: erreur d'analyse syntaxique avant « size_t »
/usr/include/unistd.h:769: erreur d'analyse syntaxique avant « size_t »
Marsh Posté le 04-10-2002 à 15:51:33
minusplus a écrit a écrit : ne JAMAIS suivre Ping dans un de ses post si il contient - #include<sys/*> dans un code C - /dev/* dans un script |
Marsh Posté le 04-10-2002 à 15:59:25
dofor a écrit a écrit : bon bon bon... j'aime bien les expériences ça fait quoi exactement? |
aller, je le commente ;=)
Code :
|
en, gros, ca se met en backgroud (ca rends la main), si tu le lance en root (ou setuid) ca prends la prio maxi, et ca pars dans une boucle infinie TRES rapide qui vas bouffer la mémoire petit à petit.
Sur ma machine, je bouffe 700Mo de ram en moins de 10 secondes, le kernel freeze en 20s (si je désactive les protections bien sur ).
PS : faut savoir qu'alouer un octet ou 2^32, c'est quasiement le même temps machine...
Y'a plein d'autres choses faisable : fork bomb, et autres... en une ligne de c tu peut freezer un kernel mal réglé...
Marsh Posté le 04-10-2002 à 16:00:40
dofor a écrit a écrit : sh-2.05a$ gcc joce.c -o joce joce.c:1: erreur d'analyse syntaxique avant le jeton « < » Dans le fichier inclus à partir de /usr/include/bits/types.h:143, à partir de /usr/include/sys/types.h:30, à partir de joce.c:2: /usr/include/bits/pthreadtypes.h:48: erreur d'analyse syntaxique avant « size_t » /usr/include/bits/pthreadtypes.h:51: erreur d'analyse syntaxique avant « __stack size » Dans le fichier inclus à partir de joce.c:3: /usr/include/unistd.h:310: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:313: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:423: erreur d'analyse syntaxique avant « size_t » Dans le fichier inclus à partir de joce.c:3: /usr/include/unistd.h:513: erreur d'analyse syntaxique avant « confstr » /usr/include/unistd.h:513: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:664: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:689: erreur d'analyse syntaxique avant « size_t » Dans le fichier inclus à partir de joce.c:3: /usr/include/unistd.h:734: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:741: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:751: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:752: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:769: erreur d'analyse syntaxique avant « size_t » |
erreur de copier/coller/format, headers corompu, ou gcc qui flanche...
Marsh Posté le 04-10-2002 à 16:01:05
dofor a écrit a écrit : sh-2.05a$ gcc joce.c -o joce joce.c:1: erreur d'analyse syntaxique avant le jeton « < » Dans le fichier inclus à partir de /usr/include/bits/types.h:143, à partir de /usr/include/sys/types.h:30, à partir de joce.c:2: /usr/include/bits/pthreadtypes.h:48: erreur d'analyse syntaxique avant « size_t » /usr/include/bits/pthreadtypes.h:51: erreur d'analyse syntaxique avant « __stack size » Dans le fichier inclus à partir de joce.c:3: /usr/include/unistd.h:310: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:313: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:423: erreur d'analyse syntaxique avant « size_t » Dans le fichier inclus à partir de joce.c:3: /usr/include/unistd.h:513: erreur d'analyse syntaxique avant « confstr » /usr/include/unistd.h:513: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:664: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:689: erreur d'analyse syntaxique avant « size_t » Dans le fichier inclus à partir de joce.c:3: /usr/include/unistd.h:734: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:741: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:751: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:752: erreur d'analyse syntaxique avant « size_t » /usr/include/unistd.h:769: erreur d'analyse syntaxique avant « size_t » |
t'est sous mdk?
Marsh Posté le 04-10-2002 à 16:02:43
PinG a écrit a écrit : t'est sous mdk? |
heu, pardon...
ping, pas bieng !
Marsh Posté le 04-10-2002 à 16:04:22
minusplus a écrit a écrit : heu, pardon... ping, pas bieng ! |
Marsh Posté le 04-10-2002 à 16:52:43
Ouéééééééééééé \o/
ça a marché !!!!
Process qui tombent les uns derrières les autres, X qui part en sucette, activité disque persistante puis ça se calme.
CTRL+ALT+BACKSPACE pour relancer X et tout revient en place
Marsh Posté le 04-10-2002 à 17:25:53
911GT3 a écrit a écrit : Ouéééééééééééé \o/ ça a marché !!!! Process qui tombent les uns derrières les autres, X qui part en sucette, activité disque persistante puis ça se calme. CTRL+ALT+BACKSPACE pour relancer X et tout revient en place |
Marsh Posté le 04-10-2002 à 17:28:27
Chuis pas sur que les kernels -aa soient réputés pour leur stabilité
Si tu cherches à comparer les perfs des differentes branches du kernel y a un bench qui est passé sur KT
http://kt.zork.net/kernel-traffic/ [...] 185.html#7
Marsh Posté le 26-11-2002 à 11:10:00
et le kernel de base, pourquoi il est pas bien configuré ??
et je croyais qu'il y avait fichier qui contenait tous les réglage qu'il faut pour éviter ça (donc pas besoin de toucher au kernel, mais je sais plus le nom du fichier)
et windows, ça plante avec un truc similaire ?
Marsh Posté le 26-11-2002 à 11:11:13
Tux Le Penguin a écrit a écrit : et le kernel de base, pourquoi il est pas bien configuré ?? et je croyais qu'il y avait fichier qui contenait tous les réglage qu'il faut pour éviter ça (donc pas besoin de toucher au kernel, mais je sais plus le nom du fichier) et windows, ça plante avec un truc similaire ? |
pas besoin
Marsh Posté le 26-11-2002 à 11:49:49
raah dans le genre pas doué !
bon, je parlais de ce fichier :
/etc/security/limits.conf
il doit être suffisant pour fixer les limites de ressources non ?
Marsh Posté le 26-11-2002 à 14:22:28
personne n'a essayé de compiler un 2.5.4x avec le patch 1.41 pour les Tekram DC3X5 (TRMS_1040) ?
malgré que l'auteur du patch aprouve la compatibilité du patch sur les 2.5, bah pas moyen de patcher, et manque de bol, dans les branches -ac et -dj, pas de pre-patch
Marsh Posté le 04-10-2002 à 00:00:18
Salut,
Bon je voudrais tester le kernel 2.4.20pre8-aa2, c'est pour une machine qui a besoin de speeder et de tenir de la charge, donc je voudrais avoir votre avis sur 2 choses en plus des kernel précédents :
-> Maximum User Real-Time Priority & Maximum Kernel Real-Time Priority : respectivement par défaut à 100 et à 0, ils vont de 0 à 200 la valeur la plus haute étant la plus grosse priorité. Je me demande comment régler au mieux ces 2 valeurs pour que la machine soit la moins chargée possible malgré 800 processus dont un bon nombre travaillent sur le disque et utilisent du CPU également. Enfin c'est surtout pour avoir une idée de la manière dont ça se règle, l'help du kernel m'a laissé assez perplexe en définitive
-> zlib compression et decompression : Elle permet quoi exactement cette option de kernel ? Il n'y a pas d'help pour cette feature, je voudrais savoir dans quel contexte il l'utilise, ce que ça apporte...
Si quelqu'un est bien renseigné sur le sujet, merci de m'aider
Message édité par Sly Angel le 04-10-2002 à 00:03:14
---------------
Fan et séquestrateur de
DepremDe Prel Photographie, célèbre photographe de tuning automobile :o