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 [EMAIL PROTECTED]
F-01710 Thoiry |tel::portable +41(0)78/665-9701
|tel::maison +33(0)450/41-1240
|tel::travail +41(0)22/379-2356
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
