[Kos-dev] Un peu de nouveau

[Thomas Petazzoni]

Salut,

Tout le monde est mort ? ;-)

Thomas

On Fri, Sep 10, 2004 at 12:35:30AM +0200, Thomas Petazzoni wrote :
> 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

> 
> 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.
> _______________________________________________
> Kos-dev mailing list
> Kos-dev at doors.enix.org
> http://the-doors.enix.org/cgi-bin/mailman/listinfo/kos-dev


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