Bonjour,
je suis confronte a un bug curieux.
Des que je scrolle une fenetre, tout le systeme se ralentit.
Exemple, je descends l'ascenceur dans abiword, xmms se met a jouer
les mp3 au ralenti.
Je fait un cat sur un gros fichier, idem. Je me deplace avec
less, meme probleme.
Une idee d'ou ca pourrait venir?
Merci
XFree 4.4, linux 2.6.5
X-post avec follow-up sur fcolc.
--
Kevin
Je me souviens que la derniere fois que je l'ai vu faire ca..
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-
On Wed, 21 Apr 2004 11:34:48 +0000, françois wrote:
françois wrote:
Thibaut Paumard wrote:
Kevin DENIS wrote:
J'ai essaye un noyau 2.4 et un 2.5 -> meme probleme. A force de tester, je me rends compte que plus la fenetre est grande (abiword ou xterm) plus ca ralentit facilement. C'est curieux ce truc.
Salut
xfree4.4 + 2.6 + kde ou gnome +mp3 ==> le tout sur un pII 266 te pose pas trop de question !
le mieux serai d'adapter ta machine avec des logiciels bcp moins gourmand :genre fluxbox ou ice pour le wm , d'eviter la préemption au niveau du kernel, niveau matos : prendre de la mémoire ............
Je suis allez un peu trop vite .
Au niveau de la préemption en faite je ne sais pas trop : quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que cela dépend de la puissance du processeur?) pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources, puisqu'il faut sauver entièrement l'état du processeur et restaurer l'état d'un autre process. De plus, sur x86, les interruptions sont très couteuses également puisque le CPU se sert de la pile (donc de la RAM) pour changer de mode d'execution. Or le switch de process se fait avec une interruption de timer... Ce point n'est pas vrai avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Donc, sur PC, il faut vraiment éviter les switches de process (donc limiter l'usage des threads), éviter autant que possible les syscalls, ..., tout ce qui change le mode d'execution du CPU. Sur 2.6, le timer est à 1000 Hz par défaut. Sur une machine peu puissante, il vaut mieux le remettre à 100 Hz pour limiter le nombre de switches.
c'est faisable par /proc ou faut-il modifier les sources ?
De plus, un 2.6 étant plus gros qu'un 2.4, il consomera plus de RAM (non swappable) et génèrera donc plus de fautes de pages (qui sont des exceptions) qui ralentiront le système. La préemption du kernel, elle, ne changera pas grand chose au nombre de switches de process mais complique un peu le kernel. Mais le gain global doit largement compenser la perte minime de performances.
il vaut donc mieux utiliser la préemption sur tous proc (même les "vieux")
intuitivement je dirai oui ==> c'est bien le noyau qui gère le "passage" d'un processus à un autre et non plus le processus qui décide de donner la main à un autre processus ??
Oui. Le threading coopératif existe encore quand on fait des threads en mode user (c.a.d sans se servir des threads kernel). Mais le switch de process est entièrement préemptif et géré par le noyau.
Merci ,cela répond (en partie ,mais c'est un vaste sujet) aux questions que je me pose sur la gestion des process(et par conséquent des threads) par le noyau .
no_spam wrote:
On Wed, 21 Apr 2004 11:34:48 +0000, françois wrote:
françois wrote:
Thibaut Paumard wrote:
Kevin DENIS wrote:
J'ai essaye un noyau 2.4 et un 2.5 -> meme probleme.
A force de tester, je me rends compte que plus la fenetre est grande
(abiword ou xterm) plus ca ralentit facilement. C'est curieux ce truc.
Salut
xfree4.4 + 2.6 + kde ou gnome +mp3 ==> le tout sur un pII 266
te pose pas trop de question !
le mieux serai d'adapter ta machine avec des logiciels bcp moins
gourmand :genre fluxbox ou ice pour le wm , d'eviter la préemption au
niveau du kernel, niveau matos : prendre de la mémoire ............
Je suis allez un peu trop vite .
Au niveau de la préemption en faite je ne sais pas trop :
quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que
cela dépend de la puissance du processeur?)
pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources,
puisqu'il faut sauver entièrement l'état du processeur et restaurer
l'état d'un autre process. De plus, sur x86, les interruptions sont
très couteuses également puisque le CPU se sert de la pile (donc
de la RAM) pour changer de mode d'execution. Or le switch de process
se fait avec une interruption de timer... Ce point n'est pas vrai
avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Donc, sur PC, il faut vraiment éviter les switches de process (donc
limiter l'usage des threads), éviter autant que possible les syscalls,
..., tout ce qui change le mode d'execution du CPU.
Sur 2.6, le timer est à 1000 Hz par défaut. Sur une machine
peu puissante, il vaut mieux le remettre à 100 Hz pour limiter le
nombre de switches.
c'est faisable par /proc ou faut-il modifier les sources ?
De plus, un 2.6 étant plus gros qu'un 2.4, il consomera plus de RAM
(non swappable) et génèrera donc plus de fautes de pages (qui sont
des exceptions) qui ralentiront le système.
La préemption du kernel, elle, ne changera pas grand chose au nombre de
switches de process mais complique un peu le kernel. Mais le gain global
doit largement compenser la perte minime de performances.
il vaut donc mieux utiliser la préemption sur tous proc (même les "vieux")
intuitivement je dirai oui ==> c'est bien le noyau qui gère le "passage"
d'un processus à un autre et non plus le processus qui décide de donner
la main à un autre processus ??
Oui. Le threading coopératif existe encore quand on fait des threads
en mode user (c.a.d sans se servir des threads kernel). Mais le
switch de process est entièrement préemptif et géré par le noyau.
Merci ,cela répond (en partie ,mais c'est un vaste sujet) aux questions
que je me pose sur la gestion des process(et par conséquent des threads)
par le noyau .
On Wed, 21 Apr 2004 11:34:48 +0000, françois wrote:
françois wrote:
Thibaut Paumard wrote:
Kevin DENIS wrote:
J'ai essaye un noyau 2.4 et un 2.5 -> meme probleme. A force de tester, je me rends compte que plus la fenetre est grande (abiword ou xterm) plus ca ralentit facilement. C'est curieux ce truc.
Salut
xfree4.4 + 2.6 + kde ou gnome +mp3 ==> le tout sur un pII 266 te pose pas trop de question !
le mieux serai d'adapter ta machine avec des logiciels bcp moins gourmand :genre fluxbox ou ice pour le wm , d'eviter la préemption au niveau du kernel, niveau matos : prendre de la mémoire ............
Je suis allez un peu trop vite .
Au niveau de la préemption en faite je ne sais pas trop : quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que cela dépend de la puissance du processeur?) pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources, puisqu'il faut sauver entièrement l'état du processeur et restaurer l'état d'un autre process. De plus, sur x86, les interruptions sont très couteuses également puisque le CPU se sert de la pile (donc de la RAM) pour changer de mode d'execution. Or le switch de process se fait avec une interruption de timer... Ce point n'est pas vrai avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Donc, sur PC, il faut vraiment éviter les switches de process (donc limiter l'usage des threads), éviter autant que possible les syscalls, ..., tout ce qui change le mode d'execution du CPU. Sur 2.6, le timer est à 1000 Hz par défaut. Sur une machine peu puissante, il vaut mieux le remettre à 100 Hz pour limiter le nombre de switches.
c'est faisable par /proc ou faut-il modifier les sources ?
De plus, un 2.6 étant plus gros qu'un 2.4, il consomera plus de RAM (non swappable) et génèrera donc plus de fautes de pages (qui sont des exceptions) qui ralentiront le système. La préemption du kernel, elle, ne changera pas grand chose au nombre de switches de process mais complique un peu le kernel. Mais le gain global doit largement compenser la perte minime de performances.
il vaut donc mieux utiliser la préemption sur tous proc (même les "vieux")
intuitivement je dirai oui ==> c'est bien le noyau qui gère le "passage" d'un processus à un autre et non plus le processus qui décide de donner la main à un autre processus ??
Oui. Le threading coopératif existe encore quand on fait des threads en mode user (c.a.d sans se servir des threads kernel). Mais le switch de process est entièrement préemptif et géré par le noyau.
Merci ,cela répond (en partie ,mais c'est un vaste sujet) aux questions que je me pose sur la gestion des process(et par conséquent des threads) par le noyau .
no_spam
On Thu, 22 Apr 2004 11:20:57 +0000, françois wrote:
Au niveau de la préemption en faite je ne sais pas trop : quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que cela dépend de la puissance du processeur?) pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources, puisqu'il faut sauver entièrement l'état du processeur et restaurer l'état d'un autre process. De plus, sur x86, les interruptions sont très couteuses également puisque le CPU se sert de la pile (donc de la RAM) pour changer de mode d'execution. Or le switch de process se fait avec une interruption de timer... Ce point n'est pas vrai avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Sur PPC, par exemple, une exception consiste à sauver 2 registres dans des registres dédiés à ça et à faire un jump à l'addresse du handler d'exception. Il n'y a pas d'accès RAM, donc c'est très rapide. Bien sur, s'il y a un switch de contexte, l'OS doit toujours sauver l'état complet du CPU, mais ça n'est pas forcément indispensable. Sur x86, le CPU se sert de la pile lors du traitement de l'exception, ce qui peut en plus conduire à générer des doubles ou triples fautes si le pointeur de pile est corrompu (la triple faute arrête le CPU...). Pas de risque de ce genre avec un PPC...
Donc, sur PC, il faut vraiment éviter les switches de process (donc limiter l'usage des threads), éviter autant que possible les syscalls, ..., tout ce qui change le mode d'execution du CPU. Sur 2.6, le timer est à 1000 Hz par défaut. Sur une machine peu puissante, il vaut mieux le remettre à 100 Hz pour limiter le nombre de switches.
c'est faisable par /proc ou faut-il modifier les sources ?
Non, je ne crois pas. Il faut le selectionner à la config du noyau. Ca serait difficile (mais pas impossible...) de changer la fréquence du timer au run-time...
De plus, un 2.6 étant plus gros qu'un 2.4, il consomera plus de RAM (non swappable) et génèrera donc plus de fautes de pages (qui sont des exceptions) qui ralentiront le système. La préemption du kernel, elle, ne changera pas grand chose au nombre de switches de process mais complique un peu le kernel. Mais le gain global doit largement compenser la perte minime de performances.
il vaut donc mieux utiliser la préemption sur tous proc (même les "vieux")
Ca génèrera un peu plus de switch de processes puisque les threads kernel pourront être préemptés, mais comme on y passe en principe peu de temps, globalement, ça ne pénalisera pas. Par contre, la réactivité sera toujours améliorée...
On Thu, 22 Apr 2004 11:20:57 +0000, françois wrote:
Au niveau de la préemption en faite je ne sais pas trop :
quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que
cela dépend de la puissance du processeur?)
pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources,
puisqu'il faut sauver entièrement l'état du processeur et restaurer
l'état d'un autre process. De plus, sur x86, les interruptions sont
très couteuses également puisque le CPU se sert de la pile (donc
de la RAM) pour changer de mode d'execution. Or le switch de process
se fait avec une interruption de timer... Ce point n'est pas vrai
avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Sur PPC, par exemple, une exception consiste à sauver 2 registres
dans des registres dédiés à ça et à faire un jump à l'addresse du
handler d'exception. Il n'y a pas d'accès RAM, donc c'est très rapide.
Bien sur, s'il y a un switch de contexte, l'OS doit toujours sauver
l'état complet du CPU, mais ça n'est pas forcément indispensable.
Sur x86, le CPU se sert de la pile lors du traitement de l'exception,
ce qui peut en plus conduire à générer des doubles ou triples fautes
si le pointeur de pile est corrompu (la triple faute arrête le CPU...).
Pas de risque de ce genre avec un PPC...
Donc, sur PC, il faut vraiment éviter les switches de process (donc
limiter l'usage des threads), éviter autant que possible les syscalls,
..., tout ce qui change le mode d'execution du CPU.
Sur 2.6, le timer est à 1000 Hz par défaut. Sur une machine
peu puissante, il vaut mieux le remettre à 100 Hz pour limiter le
nombre de switches.
c'est faisable par /proc ou faut-il modifier les sources ?
Non, je ne crois pas. Il faut le selectionner à la config du noyau.
Ca serait difficile (mais pas impossible...) de changer la fréquence
du timer au run-time...
De plus, un 2.6 étant plus gros qu'un 2.4, il consomera plus de RAM
(non swappable) et génèrera donc plus de fautes de pages (qui sont
des exceptions) qui ralentiront le système.
La préemption du kernel, elle, ne changera pas grand chose au nombre de
switches de process mais complique un peu le kernel. Mais le gain global
doit largement compenser la perte minime de performances.
il vaut donc mieux utiliser la préemption sur tous proc (même les "vieux")
Ca génèrera un peu plus de switch de processes puisque les threads
kernel pourront être préemptés, mais comme on y passe en principe
peu de temps, globalement, ça ne pénalisera pas. Par contre, la
réactivité sera toujours améliorée...
On Thu, 22 Apr 2004 11:20:57 +0000, françois wrote:
Au niveau de la préemption en faite je ne sais pas trop : quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que cela dépend de la puissance du processeur?) pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources, puisqu'il faut sauver entièrement l'état du processeur et restaurer l'état d'un autre process. De plus, sur x86, les interruptions sont très couteuses également puisque le CPU se sert de la pile (donc de la RAM) pour changer de mode d'execution. Or le switch de process se fait avec une interruption de timer... Ce point n'est pas vrai avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Sur PPC, par exemple, une exception consiste à sauver 2 registres dans des registres dédiés à ça et à faire un jump à l'addresse du handler d'exception. Il n'y a pas d'accès RAM, donc c'est très rapide. Bien sur, s'il y a un switch de contexte, l'OS doit toujours sauver l'état complet du CPU, mais ça n'est pas forcément indispensable. Sur x86, le CPU se sert de la pile lors du traitement de l'exception, ce qui peut en plus conduire à générer des doubles ou triples fautes si le pointeur de pile est corrompu (la triple faute arrête le CPU...). Pas de risque de ce genre avec un PPC...
Donc, sur PC, il faut vraiment éviter les switches de process (donc limiter l'usage des threads), éviter autant que possible les syscalls, ..., tout ce qui change le mode d'execution du CPU. Sur 2.6, le timer est à 1000 Hz par défaut. Sur une machine peu puissante, il vaut mieux le remettre à 100 Hz pour limiter le nombre de switches.
c'est faisable par /proc ou faut-il modifier les sources ?
Non, je ne crois pas. Il faut le selectionner à la config du noyau. Ca serait difficile (mais pas impossible...) de changer la fréquence du timer au run-time...
De plus, un 2.6 étant plus gros qu'un 2.4, il consomera plus de RAM (non swappable) et génèrera donc plus de fautes de pages (qui sont des exceptions) qui ralentiront le système. La préemption du kernel, elle, ne changera pas grand chose au nombre de switches de process mais complique un peu le kernel. Mais le gain global doit largement compenser la perte minime de performances.
il vaut donc mieux utiliser la préemption sur tous proc (même les "vieux")
Ca génèrera un peu plus de switch de processes puisque les threads kernel pourront être préemptés, mais comme on y passe en principe peu de temps, globalement, ça ne pénalisera pas. Par contre, la réactivité sera toujours améliorée...
françois
no_spam wrote:
On Thu, 22 Apr 2004 11:20:57 +0000, françois wrote:
Au niveau de la préemption en faite je ne sais pas trop : quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que cela dépend de la puissance du processeur?) pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources, puisqu'il faut sauver entièrement l'état du processeur et restaurer l'état d'un autre process. De plus, sur x86, les interruptions sont très couteuses également puisque le CPU se sert de la pile (donc de la RAM) pour changer de mode d'execution. Or le switch de process se fait avec une interruption de timer... Ce point n'est pas vrai avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Sur PPC, par exemple, une exception consiste à sauver 2 registres dans des registres dédiés à ça et à faire un jump à l'addresse du handler d'exception. Il n'y a pas d'accès RAM, donc c'est très rapide. Bien sur, s'il y a un switch de contexte, l'OS doit toujours sauver l'état complet du CPU, mais ça n'est pas forcément indispensable. Sur x86, le CPU se sert de la pile lors du traitement de l'exception, ce qui peut en plus conduire à générer des doubles ou triples fautes si le pointeur de pile est corrompu (la triple faute arrête le CPU...). Pas de risque de ce genre avec un PPC...
MERCI pour les réponses précise , cela fait toujours plaisir !!!!
no_spam wrote:
On Thu, 22 Apr 2004 11:20:57 +0000, françois wrote:
Au niveau de la préemption en faite je ne sais pas trop :
quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que
cela dépend de la puissance du processeur?)
pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources,
puisqu'il faut sauver entièrement l'état du processeur et restaurer
l'état d'un autre process. De plus, sur x86, les interruptions sont
très couteuses également puisque le CPU se sert de la pile (donc
de la RAM) pour changer de mode d'execution. Or le switch de process
se fait avec une interruption de timer... Ce point n'est pas vrai
avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Sur PPC, par exemple, une exception consiste à sauver 2 registres
dans des registres dédiés à ça et à faire un jump à l'addresse du
handler d'exception. Il n'y a pas d'accès RAM, donc c'est très rapide.
Bien sur, s'il y a un switch de contexte, l'OS doit toujours sauver
l'état complet du CPU, mais ça n'est pas forcément indispensable.
Sur x86, le CPU se sert de la pile lors du traitement de l'exception,
ce qui peut en plus conduire à générer des doubles ou triples fautes
si le pointeur de pile est corrompu (la triple faute arrête le CPU...).
Pas de risque de ce genre avec un PPC...
MERCI pour les réponses précise , cela fait toujours plaisir !!!!
On Thu, 22 Apr 2004 11:20:57 +0000, françois wrote:
Au niveau de la préemption en faite je ne sais pas trop : quelqu'un pourrai me dire si il faut beaucoup de ressources (est-ce que cela dépend de la puissance du processeur?) pour que ce mode soit efficace ?
Le switch de process consome forcément pas mal de ressources, puisqu'il faut sauver entièrement l'état du processeur et restaurer l'état d'un autre process. De plus, sur x86, les interruptions sont très couteuses également puisque le CPU se sert de la pile (donc de la RAM) pour changer de mode d'execution. Or le switch de process se fait avec une interruption de timer... Ce point n'est pas vrai avec la plupart des CPU modernes.
Comment ils s'y prennent alors ?
Sur PPC, par exemple, une exception consiste à sauver 2 registres dans des registres dédiés à ça et à faire un jump à l'addresse du handler d'exception. Il n'y a pas d'accès RAM, donc c'est très rapide. Bien sur, s'il y a un switch de contexte, l'OS doit toujours sauver l'état complet du CPU, mais ça n'est pas forcément indispensable. Sur x86, le CPU se sert de la pile lors du traitement de l'exception, ce qui peut en plus conduire à générer des doubles ou triples fautes si le pointeur de pile est corrompu (la triple faute arrête le CPU...). Pas de risque de ce genre avec un PPC...
MERCI pour les réponses précise , cela fait toujours plaisir !!!!
