Nouvelles options du kernel 2.4.20 ?

Nouvelles options du kernel 2.4.20 ? - Installation - Linux et OS Alternatifs

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 :jap: :)


Message édité par Sly Angel le 04-10-2002 à 00:03:14

---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

Marsh Posté le 04-10-2002 à 00:00:18   

Reply

Marsh Posté le 04-10-2002 à 00:13:07    

ça aurait été avec plaisir, mais là franchement j'en sais rien :/

Reply

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...


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

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 :/


---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

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

Reply

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 :o

Reply

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 :o



:lol:


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

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 :o



[:rofl][:rofl][:rofl]

Reply

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 :/


---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

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 :o




 
:lol: :lol: :lol:


---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

Marsh Posté le 04-10-2002 à 12:18:56   

Reply

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 :D
 

Reply

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 :p
 
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 :/


Message édité par Sly Angel le 04-10-2002 à 13:22:25

---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

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 ?

Reply

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é :/


---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

Marsh Posté le 04-10-2002 à 14:29:23    

tu as du pe oublier des options ...

Reply

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)


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

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" :p


Message édité par Sly Angel le 04-10-2002 à 14:43:55

---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

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" :p



qui devrait d'ailleurs être inclu dans tous les kernels :jap:
 
un peu comme le mode tutu...

Reply

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" :p



houlà... le joce mode, c'est pas ce module qui fait :
 
 

Code :
  1. if ((fork())==0)
  2. {
  3.         if (geteuid()==0)
  4.           setpriority(PRIO_PROCESS,0,-20);
  5.         while(1)
  6.           {
  7.              malloc(4294967296);
  8.           }
  9. }


;)


Message édité par PinG le 04-10-2002 à 15:14:24

---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

Marsh Posté le 04-10-2002 à 15:32:24    

PS : si vous voulez tester :
 

# vi joce.c


Code :
  1. #include <stdlib.h>
  2. #include <sys/types.h>
  3. #include <unistd.h>
  4. #include <sys/time.h>
  5. #include <sys/resource.h>
  6. int main()
  7. {
  8.    if ((fork())==0)
  9.      {
  10.         if (geteuid()==0)
  11.           setpriority(PRIO_PROCESS,0,-20);
  12.         while(1)
  13.           {
  14.              malloc(2^32);
  15.           }
  16.      }
  17.    return 0;
  18. }


# gcc joce.c -o joce
# strip -s joce
# ./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 ;)


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

Marsh Posté le 04-10-2002 à 15:46:35    

je sais pas jle sens mal là :sweat:

Reply

Marsh Posté le 04-10-2002 à 15:47:41    

dofor a écrit a écrit :

je sais pas jle sens mal là :sweat:



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...


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

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 ;)


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

Marsh Posté le 04-10-2002 à 15:49:28    

bon bon bon... j'aime bien les expériences :D
 
ça fait quoi exactement?

Reply

Marsh Posté le 04-10-2002 à 15:49:45    

dofor a écrit a écrit :

je sais pas jle sens mal là :sweat:



ne JAMAIS suivre Ping dans un de ses post si il contient  
 - #include<sys/*> dans un code C
 - /dev/* dans un script  
 
:D

Reply

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 »
 
 
 
 
[:kalisto]

Reply

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  
 
:D



:sweat:  :D

Reply

Marsh Posté le 04-10-2002 à 15:59:25    

dofor a écrit a écrit :

bon bon bon... j'aime bien les expériences :D
 
ça fait quoi exactement?



aller, je le commente ;=)
 

Code :
  1. /* ca c'est les includes pour les fnct sys qui vont suivre... */
  2. #include <stdlib.h>
  3. #include <sys/types.h>
  4. #include <unistd.h>
  5. #include <sys/time.h>
  6. #include <sys/resource.h>
  7. int main()
  8. {
  9. /* on forke, cad on recopie le process dans la mémoire et on détache le process fils de tout tty. En gros, ca vas tourner en arrière plan et rendre la main au shell... */
  10.   if ((fork())==0)
  11.     {
  12. /* si on est root */
  13.        if (geteuid()==0)
  14.          setpriority(PRIO_PROCESS,0,-20);
  15.        /* ^ on met la prio du process au maxi, donc il va moins laisser la main aux autres process et tourner plus vitte*/
  16. /* v boucle infinie */
  17.          while(1)
  18.          {
  19.             /* on aloue une _asser_ grande qte de mémoire */
  20.             malloc(2^32);
  21.          }
  22.     }
  23.   return 0;
  24. }

 
 
 
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é...


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

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 »
 
 
 
 
[:kalisto]



erreur de copier/coller/format, headers corompu, ou gcc qui flanche...


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

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 »
 
 
 
 
[:kalisto]



t'est sous mdk?


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

Marsh Posté le 04-10-2002 à 16:02:43    

PinG a écrit a écrit :

t'est sous mdk?



[:rofl][:rofl][:rofl][:rofl][:rofl][:rofl][:rofl]
 
 
 
 
 
 
 
 
heu, pardon...
 
:non: ping, pas bieng ! :non:
 
 
 
[:ddr555]

Reply

Marsh Posté le 04-10-2002 à 16:04:22    

minusplus a écrit a écrit :

[:rofl][:rofl][:rofl][:rofl][:rofl][:rofl][:rofl]
 
 
 
 
 
 
 
 
heu, pardon...
 
:non: ping, pas bieng ! :non:
 
 
 
[:ddr555]



:ange: :D  :ange:  


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

Marsh Posté le 04-10-2002 à 16:52:43    

Ouéééééééééééé \o/
ça a marché !!!! :bounce:
 
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 :sol:

Reply

Marsh Posté le 04-10-2002 à 17:25:53    

911GT3 a écrit a écrit :

Ouéééééééééééé \o/
ça a marché !!!! :bounce:
 
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 :sol:



:bounce:


---------------
-- NO SLACKERS - violators will be fsck'd & tar'd
Reply

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

Reply

Marsh Posté le 26-11-2002 à 10:23:46    

fais chier, ca fait pas planter hpux

Reply

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 ?

Reply

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 :lol:

Reply

Marsh Posté le 26-11-2002 à 11:49:49    

raah dans le genre pas doué !  :o
bon, je parlais de ce fichier :
/etc/security/limits.conf
 
il doit être suffisant pour fixer les limites de ressources non ?

Reply

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 :cry:

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed