[Kos-dev] Suppression du gpfme->lock

[Thomas Petazzoni]

d2 <David.Decotigny@irisa.fr> writes:

> Hello,

Hello !

> Il y a maintenant un create_kernel_rmap => c'est dans le post-init
> arch-mm. Pas trop teste, mais a priori ca marche. Moyennant 1 page
> allouee par le loader mais mappee nulle part dans la zone du
> core_kernel => je l'ai viree par put_physical_page(). Faudrait
> cependant voir ou le loader l'alloue (ds le code) et a quoi elle
> correspond. Avec 4M de RAM, c'est la page physique 3fe000 (cf msg de
> debug rouge a l'init arch-mm). Pour tester le create_kernel_rmap, il
> faudrait faire la fonction qui bouge une page virtuelle en physique
> ("remap" on l'avait appelee).

=> Cf mon log de commit, j'ai change tout ca. Les pages que tu savais
d'ou elles venaient moi je sais, et je te dirais pas ;)) Nan je
rigole. C'est tout simplement les PTs alloues par le loader pour
l'identity mapping, et qui ne serve plus apres. On voulait justement
les virer, et ca nous embetait... Maintenant c'est fait, c'est tout
bon !

> Le pb du gpfme->lock n'est pas lie au create_kernel_rmap(), qui, en
> l'etat, est effectue dans le post_init arch/mm, avec interruptions
> locales desactivees autour (donc safe au regard des locks qu'on prend
> => aucun lock veritablement necessaire).

Maintenant le create_kernel_rmap est en INIT_LEVEL1, donc
interruptions COMPLETEMENT desactivees (faudra que je fasse un tour,
je crois qu'on acquiert des locks inutiles donc).

> Non. Avec 1 lock par gpfme, l'idee c'est que qd je locke le gpfme, je
> veux etre assure qu'il ne change pas : rien, meme pas le ref_cnt, ni
> les flags page_type/swap_status, ET prev/next ne changent. Or,
> prev/next dependent directement des listes, donc, logiquement, si on
> doit bouger un gpfme d'une liste a l'autre, il faut acquerir le lock
> des listes, et 5 locks : le gpfme a bouger, les locks sur les
> prev/next de la liste source, les locks sur les prev/next de la liste
> destination. Au passage, concernant le pb d'ordre de locking
> liste/gpfme : un ordre est convenable pour certaines primitives, et
> l'ordre oppose l'est pour d'autres.

Effectivement, je vois le merdier. En fait l'objet gpfme est protege
par deux locks distincts, et c'est ca qui va pas.

>   - de construire le sieve_gpfm comme on le fait actuellement, ce qui
>     est suffisant pour allouer environ 146 pages physiques (4k/28octets)
>   - d'appeler l'init de kmem (=> mettre en route l'alloc slab)
>   - d'appeler init_rmap() et d'initialiser le rmapping pour les 4
>     pages allouees (ie le PT pour la 1ere page de gpfme, la 1ere page
>     de gpfme, la premiere page pour le slab de slab, la premiere page
>     pour le slab de rmap)
>   - d'allouer le reste du gpfm en initialisant le rmapping pr chaque
>     page : c'est facile puisque pour chaque zone mappee (video,
>     core_kernel), on connait le mapping correspondant en VM. Parce que
>     on sait comment le loader alloue+mappe le noyau, et comment la
>     video est mappee. A verifier, mais je crois que pour le
>     core_kernel, le 768M correspond a la loader_allocatable_memory, et
>     que ca descend en adresse physique alors que ca monte en adresse
>     virtuelle ; pr la video c'est encore plus facile : mapping direct
>     croissant/croissant. Qd aux pages de gpfm que le gpfm s'alloue
>     lui-meme, elles seront automatiquement rmappees puisque, a ce
>     niveau, le rmap est deja active.

J'ai pas fait exactement comme tu as dis, mais ma solution, est AMHA
beaucoup plus simple, cf log de commit.

> Seulement quand on aura fait ca, je reverrai le pb du locking plus
> fin. Pour l'instant, je laisse ca de cote. Je propose egalement que
> dans 15 jours, on ne se casse pas la tete sur ces problemes de
> proprification de l'init pmm/kmem/arch-mm (Thomas ou moi, on peut le
> faire en solo), et qu'on se concentre sur Babel.

Bonne idee, voire tres bonne idee. Au pire on se cassera un peu la
tete avec Julien dessus. Mais ceci dit, d2 faudra ptet qu'on se voit
un WE pour revoir ca.

> Bonne journee. Je ne touche plus a rien d'ici au 5. Sauf peut-etre des
> broutilles,

Okay. Nickel, comme ca je peux bosser un peu dessus. Parfois
j'hesitais a avancer sur certains trucs, a cause des conflits
CVS. Pour ma part, j'ai bien termine create_kernel_rmap (sauf bug
eventuel), vais essayer le remap, et pi peut etre avancer sur le CPL3.

Derniere question : un fichier est vu comme un peripherique caractere
au niveau de l'API Unix. Qui realise cette abstraction ? La libc ou le
noyau ? (sur disque, un fichier est plutot un peripherique en mode
bloc).

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
(Perso)      http://www.enix.org/~thomas/
(KOS)        http://kos.enix.org/ 
(Club LinUT) http://club-linut.enix.org