[Kos-dev] Quelques idées

[Raphaël Junqueira]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mardi 29 Avril 2003 23:15, Thomas Petazzoni a écrit :
> Raphaël Junqueira <fenix@club-internet.fr> writes:
>
> Hello,
Re,

> > En fait on peut facilement avoir un truc pas trop mal en ajoutant une
> > gestion des MLK dans les primitives d'allocation du noyau. On peut meme
> > atteindre des beaux raffinements en jouant avec les droits d'acces au
> > pages et avec les page faults (mais ca devient plus risquer pour la
> > stabilite du noya)
>
> Ouais, pour ce truc précis, j'avoue que je préfererais de
> l'instrumentation externe : Bochs est fait pour ça. Par contre, le
> problème c'est la mémoire virtuelle : on peut avoir plein plein de
> contextes, c'est un peu le bordel. Je vois pas trop comment gérer
> ça. Faudrait que Bochs lui même sache associer des listes d'octets
> initialisés à des contextes (des valeurs de CR3).

Je voit pas l'interet de l'instrumentation externe a part se compliquer pas 
mal la vie. C'est clair que si tu veut quelquechose de compliquer bcp trop 
intrusif dans le noyau ... mais juste pour des MLK ca doit pas etre le cas.

> Et en plus, faudrait que quand on fasse kfree(), la zone mémoire soit
> reconnu par Bochs comme étant non initialisé, donc il faudrait pouvoir
> lui signaler, en faisant un opcode invalide que Bochs comprendra, ou
> en écrivant sur un port d'I/O quelconque.
>
> Peut être un bon sujet de TX pour l'UTBM. Hum hum, pourquoi pas ;-)
>
> > En fait j'ai developpe un profileur avec des contraintes similaires
> > et ca marche pas trop mal. Mais le mieux c qd meme le profileur
> > "statistique" qui recupere une pile tous les dt et qui fournit de belles
> > stats comme on les aime ;)
>
> Effectivement le profiling ça marche comme ça d'habitude, mais je vois
> pas du tout, mais pas du tout l'intéret. 

En fait non, l'enorme majorite des profiles font de l'instrumentation de code 
en ajoutant des prefixes/suffixes aus fontions

> Il me semble qu'une solution  ou tu comptes le nombre de cycles à l'ent=
rée
> et a la sortie sera plus précis, non ?

Vi plus precise en nombre d'appels, plus precis en terme de temps atomiques de 
chaque fonctions, MAIS bcp trop intrusifs.
En clair, en contexte multi-thread noyau tu ne pourra avoir une image realiste 
du comportement/temps global de threads (car trop impacte par les "switchs" 
de l'instrumentation), tu modifiera trop le comportement du systeme (les TLB 
miss,  desynchro etc... n'arriveront plus au meme moment)
La solution statistique meme en etant moins precise (surtout pas capable 
d'avoir un nombre d'appels reelement sur) et, en plus d'etre bcp plus rapide, 
la solution qui influera le moins le comportement du noyau.

> Evidemment, tu laisses tourner le machin 10000 fois, et
> tu fais une moyenne. Ca c'est faisable.

Vi le but, c'est qu'il faut le lancer sur des scenarios assez gros (ca depend 
du dt, mais pour un dt de 2 ms, avec 2 s de tps d'exec tu commence deja a 
bien jouer)

> En revanche, si on veut les pourcentages de temps passé dans telle ou
> telle fonction, faut faire un graphe des appels, et ça on va pas
> s'amuser à le coder, il *faudrait* pouvoir réutiliser gprof.

Je vois pas la dificulter. Reutiliser gprof dans un kernel me semble bcp plus 
de la folie (surtout pour les res que l'on va finir par avoir) que coder une 
gestion de graphes)

> Enfin, bon tout ça, c'est bien gentil, mais ça fait du boulot quand
> même.

Ben vi, on aurait plus de boulot si tout se faisait sans efforts ;)

> Thomas
Raphael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ru+5p7NA3AmQTU4RAsM4AJ9TBF2xpwz677uD9sLgph/T0su6hwCZAc6D
3sMfl36Yi9+LAc5NWyWiH8Q=
=88pp
-----END PGP SIGNATURE-----