J'utilise donc a prioris les bon patchs :
  Preemption Patch : http://www.tech9.net/rml/linux/
  Low-Latency Patch : http://www.zip.com.au/~akpm/linux/ [...] #downloads
Et j'ai les sources du kernel-2.4.20, téléchargées sur kernel.org, aucun patch appliqués, dans le dossier /usr/src/linux/
 
# cd /usr/src/
# patch -p0 < preempt-kernel-rml-2.4.20-3.patch
Ca marche, ça me patch ce qu'il faut.
# patch -p0 < 2.4.20-low-latency.patch  
Là par contre ça marche pas, il me demande "File to patch:", même si je lance ce patch avant l'autre.
 
 
J'ai aussi testé la méthode debian : http://www.rycks.com/documentation [...] mpilation/
Mais j'arrive alors plus a compiler.
 
 
Merci de votre aide

Essayes -p1
 
Sinon, sur le site tu as un pack qui patche tout pour toi, c'est qd même plus pratique ...

-p1 marche, en rentrant dans /usr/src/linux/ merci
 
Aller, j'essaye de compiler maintenant

Tu vas devoir le refaire
 
Je te conseille juste, au lieu d'utiliser ces deux patches séparément, d'utiliser directement les patches -ck de Con Kolivas qui sont vraiment super, et qui en plus d'inclure les patches preempt et low latency te propose d'autres patches destinés à améliorer les performances du système. Tu peux les retrouver ici :
http://members.optusnet.com.au/ckolivas/kernel/
 
D'ailleurs, un patch complet est dispo ici (bunzip2 avant de lancer patch ) :
http://members.optusnet.com.au/cko [...] .patch.bz2

Un patch de 1.2 Mo :-D cool
 
J'ai toujours un probleme de compilation :
 

 
 
Quand ça veux pas.. Je vais essayer le patch dont tu me parle.

Ca a marché
C'est dingue ce que c'est plus réactif ous x maintenant !
Par contre avec une compilation lancé en fond ça rame comme c'est pas permis. La vie est un question de priorités

Normalement, avec ces nouveaux patches, même les compilations en fond de tâche ne devraient plus tellement ralentir les applications X
Je te conseille également la lecture de la FAQ sur le site de ck.
 
PS : Tu as déjà testé un noyau 2.5 ?

Pourtant ça rame un peu (Duron800 ). J'ai lu la faq, c'est très instructif.
 
J'ai aussi essayé un 2.5, mais il bootait pas, j'ai pas trop cherché a comprendre (bloc après lilo), y'avait pourtant des accès sur le disque après  

question: y a des changements avec le FB avec les 2.5?

Sur le framebuffer je crois bien qu'il y a eu un tonne de changement

je veux dire au niveau des options pour le noyau. par ce que quand je teste un 2.5, c'est ecran noir et reboot tout seul

Ah ok, dsl. Non, je n'ai pas mis le framebuffer, je devrais essayer ?

bon je dégage l'option /proc/.../lowlatency, j'y comprends rien et ça fonctionne pas.

Tu veux dire, le contrôle de Low Latency par sysctl ? Effectivement, ca sert à rien, désactives le
 
Sinon, pour compiler le 2.5, tout se trouve ici :
http://forum.hardware.fr/forum2.ph [...] 424&cat=11

ben j'ai déjà essayer plusieurs fois, mais comme dit plus haut, c'est ecran noir et reboot. fodrait que je vire mon vga=791 pour voir, mais j'ai la flemme

je suis entrain de recompiler mon 2.4.20, je dois m'attendre à quoi comme accélération?
 
edit: coole, je me base sur le temps que je mets à switcher entre  tabs dans phoenix, c'est plus rapide.
 
fo que je renice X ou po?

Sur mon topic, j'ai mis les citations de lucaramel qui stipulent notamment ceci :

Il y a quelques précautions à prendre avec ce nouveau noyau, elles sont toute répertoriées sur ce topic. Est-ce que tu utilises le 2.5.70 avec les patches mm ?
 
PS : Il vaut mieux renicer X comme tu peux le lire dans la FAQ.

ben je renice X, ça pert instantanément en fluidité

d'un autre coté, là je suis à 6 de charge, c'est vrai que c'est plus réactif dans mes consoles, enfin c'est peut etre un placebo

Chez moi c'est pas placebo, la différence est nette

pour quelles applications?
 
edit: finalement, le ll, c'st grosso-modo passer le quantum de temps de 100 à 10. OK, ça apporte une meilleure réacitivité. Mais est ce que ça a un impact négatif sur les longues tâches?

ouch, il me faut presque 25% de temps en plus pour mes compilations... j'ai merdé un truc ou tout le monde a un résultat comme ça?

Ce genre de patch augmente la réactivité du systeme, au détriment des performances général. Pour des grosse tâches effectivement ça ralenti un peu.
 
Chez moi on va dire que quand j'ai plusieurs fenêtres ouvertes, quand je passe de l'une a l'autre j'attend 3 fois moins detemps qu'avant pour qu'elles s'affichent. Mais une compilation dans un xterm fait tout saccader par contre. Au final je préfère quand même avec patch, mais ça conviendra peut être pas a certain

ben c'est vrai que c'est pas mal, mais je vais devoir le virer. le truc du sysctl, j'ai pas réussi à vraiment voir si ça marcher, je chercherais