[gull] ralentissement

[cedric briner]

> je publie ici, les echanges avec Daniel Cordey, la suite a est la

oummpf ! ca fait bcp d'infos a digerer d'un seul coup  :)

 > vmstat :
 >
 >     - Le CPU est utilise a 100% (- 2/3 % de temps en temps). Un CPU 
plus rapide
 >     aiderait
 >
 >     - 2 a trois process se partagent le CPU en permanence. Le minimum 
etant 2
 >
 >     - Memoire... suffisante, pas de swapping, assez de buffer-cache, etc.

qu'est-ce que le buffer-cache compare au cache

 >     - bo/bi tres faible, donc pas d'activite de paging significative. 
C'est meme     bas.

donc faible activite du HD
 >
 >     - Niveau d'interruption tres tres normal...
 >
 >     - Context-switch... anormlement eleve ! Pourquoi ? Parcequ'il n'y 
a pas     d'activite I/O... seulement du CPU. Or, un activite I/O 
impliquerait un
 >     nombre d'interruptions beaucoup plus eleve. Donc, il y a des CS 
    alors que les process sont CPU bon, et sans paging...

il faut que j'en parle pour mieux comprendre:

Voici une liste par ordre croissant des rapidites d'acces des e/s :
  - acces hd :simple ou swap (acces de la memoire mise sur le swap)
  - ram :
  - cache : la memoire la plus proche du cpu (carrement dans chipset du cpu)

donc dans mon cas, l'application psfm.exe utilise bien plus de memoire 
que ce que le cache du CPU en comporte.

Et lorsque, l'ordonnanceur (scheduler) passe d'une application a 
l'autre, l'application lorsqu'elle se charge fait plein de miss-cache 
(comptabilise comme user-time :( ). Ce qui fait que l'ordonnanceur ne 
laisse pas assez de temps a l'application interactive pour sembler 
reagir rapidement.

Donc dans mon cas le probleme vient du fait que les applications passent 
trop de temps a charger le cache sans laisser a l'une comme a l'autre le 
  temps de s'etablir.

 >
 > Mon vieux, je crois que tu es dans une situation de cache-trashing ! 
Le process 1 effectue ses operations et load des lignes de cache CPU, 
rapidement, il arrive au bout de la cache... Il genere donc un 
cache-miss, puis un autre, puis un autre... il se trouve rapidement mis 
de cote par le scheduler, un autre process arrive, cherche a remplir la 
cache avec ses donnees, genere des cache-miss... effectue une operation 
I/O, engendrant un CS... autre process, meme chose... puis re-procees 1, 
qui continue son calcul, genere des cache-miss, etc.
 >
 > Ce qui fait que les CPUs passent leur temps a avoir des cache-miss et 
ne beneficient donc pas de l'avantage du cache du CPU. Les process en 
cache-miss comptabilisent quand meme leur temp d'acces memoire comme 
'user time' et non comme systeme lorsque des donnees sont lues du 
buffer-cache du file system. Les process sont donc interrompus toutes 
les 300 musec a 1 ms. C'est une valeur beaucoup trop elevee pour un 
environementg CPU bound.
 > Comment s'en sortit ? D'abord, ne pas jouer avec nice... je trouve 
que ca ne sert a rien, si ce n'est rendre les choses plus compliquees. 
Ne surtout rien faire pour augmenter le niveau de context switch; ne pas 
reduire la valeur de 10ms pour le scheduling... ca ne fait qu'amlifier 
le probleme.
 > Le probleme du cache-thrashing est insoluble et ingerable. D'abord, 
il te suffit d'une cacahouette pour passer de 'tout-va-bien' a 'c;est 
l'horreur'. C'est un 'coude' et il n'ya pas de degradation lente. Le 
seul moyen etant de separer les process sur des CPUs differents. 
Peut-etre qu'un systeme dual-cpu apporterait une bouffe d'air, mais on 
aurait toujours l'epee de Damocles concernant le probleme de 
cache-synchronisation entre les deux CPUs. Surtout pas de dual-core... 
inutile... amoins d'avour une augmentation massive de cache CPU par 
rappport a l'existant... Autre solution, un CPU avec le 
double/triple/quadruple de CPU cache... Mais, le mieux est de mettre les 
process sur des machines separees...


ok je garde ca comme info


Est-ce que la solution qui peut etre envisagee est de reecrire le 
programme de calcul de fft de maniere a ce qu'elle travaille par partie 
et qu'elle n'utilise pas tout le cache et qu'elle en laisse pour les 
autres appli.

Ced.
P.-S. Merci je viens d'apprendre un peu trop de chose selon moi
P.-S2. Je te propose de poster ce que tu viens d'ecrire sur le gull, ce 
a quoi je repondrai par le meme mail



-- 

Cedric BRINER
71 rue des Truffes |mel briner at infomaniak.ch
F-01710 Thoiry     |tel::portable +41(0)78/665-9701
                    |tel::maison   +33(0)450/41-1240
                    |tel::travail  +41(0)22/379-2356