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

[Thomas Petazzoni]

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

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

Si tu pouvais le lire, un jour, et me dire ce que tu en penses, ca
serait vraiment bien !

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

Je suis d'accord avec toi, mais le probleme vient avant meme le
swapping ! Quand on recoit un #PF sur une page, comment on sait si
notre pere l'a deja mappee un jour ?

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

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

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