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

[d2]

Bonjour,

Tout d'abord, si y'a des trucs louches dans mon mail, c'est normal.

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@utbm.fr> writes:
    Thomas> continuations. Ceci etant dit, ils ont reussi a reduire
    Thomas> autant le nombre de piles noyau parce que leur noyau n'est
    Thomas> pas preemptif (apparemment, sinon je vois pas comment ca
    Thomas> peut marcher).

Sans avoir lu ni le papier, ni le source, c'est une remarque qui me
parait legitime. A regarder de plus pres quand meme, on ne sait
jamais.

    Thomas> Je trouverais mieux d'avoir dans chaque SR un tableau de
    Thomas> pointeurs. Le pointeur pointe soit un gpfme, soit sur une
    Thomas> structure decrivant une page swappee (genre gsfme = global

Je vois un truc plus "simple" : en ce qui concerne le swap, tout se
joue au niveau des SR anonymes. Donc, a mon avis, c'est aux SR
anonymes de maintenir la liste des gpsme. Les autres SR n'ont pas a
s'occuper de ca (si elles recoivent #PF, c'est soit differenciation,
soit recup page depuis le backing store aka le fichier original). Le
map() des SR anonymes commence par regarder si l'offset du #PF dans la
ressource est couvert par un gpsme : si oui, map() s'occupe de charger
la page swap en question, sinon, c'est vm_map + memset(avec des
zeros). Evidemment, ce mecanisme entre en jeu *apres* tout le
mecanisme de differenciation dont on avait parle
(map_shared/map_private).

    Thomas> swapped frame map entry). Vu que ces structures sont
    Thomas> alignees sur 4 octets, on peut utiliser les 2 bits de
    Thomas> poids faibles pour dire si l'adresse est celle d'un gpfme
    Thomas> ou d'un gsfme.

Peut-etre, peut-etre. Trop dans le brouillard pour comprendre
aujourd'hui.

    Thomas> Dans cet exemple la page 2 est pas dans le pere de la team
    Thomas> C, mais dans le grand pere. Et on va pas s'amuser non plus
    Thomas> a traverser l'ensemble de ses peres/grands-peres.

Pas mieux. A priori aujourd'hui la maintenant je vois pas pourquoi tu
aurais besoin de te preoccuper de la hierarchie
pere/fils/petit-fils. Mais encore une fois : je suis dans le pate donc
j'ai peut-etre le neurone difficile.

    Thomas> au telephone hier. Pour l'instant dans le noyau, on
    Thomas> utilise partout des spinlock.  Mais je me demande si

Oui, la dessus je suis tout a fait d'accord. Le probleme n'est pas
tant de savoir si on utilise spinlock plutot que semaphore (les
spinlocks empechent le noyau d'etre reentrant en UP, donc c'est vrai
qu'on y perd en reactivite), que de se mettre a utiliser serieusement
les operations atomiques (ie il doit bien y avoir des endroits ou on
locke alors qu'une simple bidouille avec les atomic_t suffirait par
exemple).

Sinon, je suis tout a fait d'accord : pour un truc comme le
get_phys_page() par exemple, le semaphore me parait *necessaire* et
pas seulement pour des raisons de reactivite (qd on est juste en pages
physiques, c'est bien que le swapper puisse entrer en action histoire
de liberer de la place).

    Thomas> Exemple typique : on parcourt l'arbre des SR (la fameuse
    Thomas> bbl_open_sr), pendant tout le temps du parcours les
    Thomas> interruptions sont desactivees (spinlock de partout) alors
    Thomas> qu'on pourrait tres bien gerer une interruption clavier
    Thomas> qui arrive par exemple !

Exemple mal choisi : le open_sr actuel ne vire pas les irq tout du
long. Il les desactive/reactive plusieurs fois au cours du
parcours. Rien n'empeche une IRQ d'etre traitee entre deux de ces
"fois".

N'empeche que sur le fond je suis d'accord avec toi. Ne pas oublier
que les semaphores augmentent la reactivite parce qu'un reschedule a
lieu. Mais ne pas oublier que ca rajoute 2 overheads : le reschedule
justement, et le chgt de contexte eventuel (ie 2 chargements des
caches). Note que le reschedule peut etre tres rapide qd meme (en
revoyant la version actuelle de A a Z).

    Thomas> Je sais pas si l'exemple ci dessus est encore valable,
    Thomas> parce qu'avec le rewrite de d2 de bbl_open_sr il me semble
    Thomas> qu'on utilise moins de lock, mais plutot un compteur de
    Thomas> ref (equivalent a une semaphore en gros).

Les 2 : spinlock pour parcourir la liste des fils, et ref_cnt pour
passer d'un fils a l'autre tout en etant sur qu'il n'est pas supprime
entre temps. Ne pas perdre de vue la fin du commentaire : "when a SR
is renamed or deleted, care must be taken * that the parent_sr is
(write) locked." sinon y'a une race condition.

Bonne journee.

-- 
d2