[Kos-dev] Un peu de nouveau

[Thomas Petazzoni]

Salut,

Si, si, cette mailing list existe toujours.

J'ai trouvé ce soir un fond de motivation, et j'ai commencé à recoder la
partie "mapping d'une page physique en mémoire virtuelle" et "gestion de
la mémoire physique", d'une part pour prendre en compte les réflexions
sur la synchro, et pour recoder certains trucs plus proprement. Par
exemple, je voudrais que le gpfme soit un structure opaque, donc le
contenu n'est connu que de pmm, de même pour les autres structures.

Niveau synchro, je commence doucement à y voir plus clair. J'ai écrit
deux ou trois notes sur le fonctionnement de la synchro dans le
traitement du #PF sous Linux. Je vois bien comment ça marche, sauf un
détail que certains d'entre vous peuvent peut être m'expliquer. A un
moment dans le traitement du #PF, ils changent l'état de la tache
courante en TASK_RUNNING, pourquoi ?

Vous trouverez ces quelques notes en fichier attaché.

J'espère continuer à trouver la même motivation la semaine prochaine.

Bonne nuit,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org 
http://thomas.enix.org - Jabber: kos_tom at sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
-------------- next part --------------

Synchronisation du #PF sous Linux (2.6)

Dans arch/i386/mm/fault.c:do_page_fault, Linux commence par
sauvegarder l'adresse de la faute (contenue dans le CR2). Dès que
c'est fait, il réactive les interruptions en utilisant
local_irq_enable() (codée dans include/asm-i386/system.h, cette macro
fait simplement sti). Il réactive donc très tôt les interruptions.

Une fois ceci fait, il prend la sémaphore mm->mmap_sem, qui est la
sémaphore sur l'espace d'adressage courant. Il la gardera tout au long
du traitement du #PF, même pendant les entrées sorties. Si j'ai bien
compris, ça permet d'utiliser la sémaphore comme une liste d'attente
pour les threads du même espace d'adressage ayant fait un #PF : ils
sont traités à la queue leu leu.

Ensuite, toujours dans la même fonction, il cherche la région
virtuelle incriminée, et si ça semble un peu correct, appelle la
fonction handle_mm_fault, codée dans mm/memory.c.

Ici, il y a une modification de l'état de la touche courante, qui
passe en TASK_RUNNING. J'ai toujours eu du mal à comprendre les
modifications des états des tâches dans Linux. Quelqu'un comprend-il
l'utilité de ce changement d'état ?

Ensuite, il prend le spinlock mm->page_table_lock, puis il alloue le
PMD et le PT si nécessaire, et enfin appelle handle_pte_fault pour
réellement traiter le #PF.

Il choisit ici comment traiter le #PF (page anonyme, page dans le
swap, page dans un fichier). Si on prend l'exemple de la fonction
do_no_page, on peut voir qu'il commence par relacher le spinlock
mm->page_table_lock, puis il réalise l'opération d'I/O (appel à
vma->vm_ops->nopage). Ensuite, il reprend le spinlock, et regarde si
quelqu'un a déjà mappé la page entre temps, si oui, il libère toute la
mémoire allouée, sinon il mappe la page au bon endroit.

On retrouve le même schéma pour l'allocation d'un PMD ou d'un PT : il
relâche le spinlock, alloue son bazar, reprend le spinlock et vérifie
si quelqu'un d'autre ne l'a pas fait entre temps.