[Kos-dev] Suppression du gpfme->lock

[d2]

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).

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).

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.

Pour l'instant j'ai tout remis a plat, j'ai refait simple, et on verra
a retravailler le locking pour faire plus fin. A mon avis il faut se
focaliser d'abord sur la base : avoir un ensemble vmm/rmap qui marche
bien, API bien claire, locks comme il faut, meme si le grain de lock
est trop gros. Une fois que tout ca sera clair (API complete, etc...)
on aura une idee plus juste sur les pbs de locks. Jusqu'ici, a chaque
fois que je voulais rajouter une fct dans arch/mm ou pmm, je
m'apercevais que les locks pmm n'etaient pas convenables, et je
changeais ces locks. En attendant d'avoir la vision complete, donc,
restons simples. Une fois qu'on l'aura stable, cette vision, on pourra
raisonner plus finement. A mon avis, il manque 2 trucs encore a cette
API : un create_kernel_rmap propre (cf dessous), et un remap_page.

Cote vmm/rmap, je vois en effet un truc qui me gene terriblement a
proprifier en priorite : le create_kernel_rmap. Je n'aime pas le fait
qu'on doive scanner l'espace virtuel gpfm+core_kernel (gpfm+128M). Je
trouverais bcp plus propre qu'on cree le rmap des le moment ou on
alloue le gpfm (puisque le gpfm s'alloue lui-meme). Ca m'a pas l'air
d'etre gd chose a faire. A vue de nez il suffit :
  - 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.

Comme ca, des le plus tot, on aura le rmapping en place, et on n'aura
pas a se casser la tete pour le construire et retrouver nos petits
"apres coup, facon bidouille" (ie comme actuellement). Non seulement
ca sera plus propre et plus beau, mais en plus ca sera plus rapide
pour bochs (pas a scanner 128M).

2 choses :
  - Le 4eme point de la methode precedente, qui consiste a utiliser ce
    qu'on sait entre l'alloc loader et le mapping VM, ne suffit plus
    quand on se place en post_init (ie actuellement). En effet, entre
    temps, il y'a eu d'autres pages physiques qui ont ete allouees par
    le noyau, et qui n'ont plus de correspondance aussi directe avec
    la mem physique (ne serait-ce que le gpfm lui-meme). C'est pour ca
    qu'on est oblige de faire le parcours des gpfm+128M de l'espace
    core_kernel et qu'on ne peut pas s'en dispenser
  - Le mode d'emploi precedent pose un """probleme""" d'ordre
    "ingenierie" : comment on fait les init ? Est-ce qu'on reserve 3
    ou 4 initlevels pour faire tout ca, ou est-ce qu'on imagine un
    super-module 'mm' qui s'occupe d'appeler les init dans le bon
    ordre (en sachant que les fonctions d'init ne peuvent pas etre en
    __init puisqu'il faut alors qu'elles soient EXPORT_SYMBOL) ?
    Perso, Je prefere sacrifier 4 initlevels pour ca, meme si la
    visibilite globale de l'ordre des init est moins evidente qu'un
    code lineaire qu'on a sous les yeux (il faut aller chercher le
    parametre passe a DECLARE_INIT_SYMBOL() dans les differents
    modules).

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.

Concernant sys, je pense que ca devrait etre un module cvs a
part. C'est clair qu'il va falloir un moyen de mettre les 2 parties
d'accord sur un certain nombre de points (debut zone cpl3, adresse
_start, et surtout stubs Babel). Mais je pense (j'espere) que ca peut
se regler a coups de gcc -Ipath/to/noyau/ .

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

-- 
d2