[Kos-dev] Piles niveau noyau, gestion du fork()

[d2]

Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> Je suis d'accord avec toi, mais le probleme vient avant
    Thomas> meme le swapping ! Quand on recoit un #PF sur une page,
    Thomas> comment on sait si notre pere l'a deja mappee un jour ?

Je vois pas trop. Apres le fork(), a la fois le AS du pere et ses PT
sont copiees vers le fils (pour l'instant, pas de COW sur les
PT). Donc pour une page donnee, soit elle a ete mappee par le pere,
auquel cas elle est mappee aussi dans le fils (cause memes PT) ; soit
elle n'est pas mappee par le pere et alors ne l'est pas non plus dans
le fils (cause memes PT). Donc si le fils fait un #PF, c'est que soit
la page est mappee dans pere et fils (cause memes PT) mais les droits
d'acces sont insuffisants (=> differenciation en utilisant rmap), soit
que ni le pere ni le fils n'ont mappe la page (=> utilisation de la
liste des VRs qui pointent vers la SR, afin de mapper la page ou il
faut chez tout le monde, en particulier chez pere et fils). Bref, je
vois pas en quoi il y aurait besoin de remonter la hierarchie
pere/fils a quelque moment que ce soit.

    Thomas> Revoir le reschedule ? Tu parles d'avoir un algo
    Thomas> d'ordonnancement potable je suppose.

Oui. Avec des jolies listes de threads bloques en attente sur synchro
(+ ptr vers la synchro), d'autres en attente d'un timeout, d'autres
prets a etre executes => ie 3 listes (sans parler de priorite pour le
moment) et 5 ou 6 etats fixes (meme si on rajoute d'autres mecanismes
de synchro). Ca me fait penser que ca serait bien que mutex,
semaphores, rwlock (qu'on n'a pas encore), kmsg et cie soient tous
descendants (heritage structurel, pas de babel pour l'instant je
pense) d'une structure commune : une synchro_t. Cette structure
renfermerait le struct thread *thread_list de kwaitqueue/ksem (a
generaliser dans : kmsg, signal, ...). Ca eviterait d'avoir a rajouter
un etat dans l'enum state, et un membre de l'union dans thread_t a
chaque fois qu'on rajoute un mecanisme de synchro. Et pour le
scheduler, c'est beaucoup plus systematique : pop de la liste des
ready si y'en a ; sinon idle.

Bonne journee,

-- 
d2