[SOS] Gestion de la mémoire, physique, paginée, virtuelle...

[Bombela]

Un grand merci pour cette réponse si intéressante !
Je désespérai d'avoir une réponse.

Tu viens de me donner matière à potasser ;)

Merci !

David Decotigny a écrit :
> Bonjour,
>
> Bombela wrote:
>   
>> Mais tout d'abord, laissez moi vous décrire cette gestion comme je l'ai
>> comprise actuellement.
>>     
>
> [ ... ]
>
> Il n'y a rien à redire à ce résumé. Tous les éléments importants sont là
> et corrects ! Ca fait plaisir ;)
>
>   
>> De plus, je crois que c'est ce gestionnaire qui doit gérer l'allocation
>> de plus petit objet
>> (allocateur slab etc...).
>>     
>
> En gros oui. Plus precisement : il y a un gestionnaire de regions
> virtuelles (des intervalles de X pages virtuelles contigues) qui permet
> a l'allocateur SLAB de fonctionner. Cet allocateur SLAB permet d'allouer
> des objets de petite taille (< 1 page) dans les regions virtuelles. Les
> deux sous-systemes (gestionnaire de mem virtuelle / SLAB) sont
> interdependants dans SOS, d'où probablement ton hesitation. Dans une
> possible 2eme iteration de SOS, je pense qu'on supprimera cette
> inter-dependance pour simplifier les explications et la comprehension.
>
>   
>> Ce gestionnaire doit :
>>  * Permettre une relation entre le gestionnaire de mémoire paginée
>>        et le gestionnaire de mémoire physique.
>>  * Gérer le callback de page fault de la mémoire paginée pour gérer le
>> swap, mappage de fichier
>>       ou erreur de programmation.
>>     
>
> Dans les faits on n'utilise pas le demand-paging dans le noyau. On ne
> l'utilise que dans le premier article sur la VMM pour montrer ce qu'est
> le demand-paging. Mais par la suite on ne l'utilise plus dans le noyau,
> il intervient seulement en cas de page fault en espace user. Donc la
> gestion du callback de page fault par ce gestionnaire VMM se reduit en
> pratique a la signalisation d'une erreur de programmation. Dans une
> possible 2eme iteration de SOS, je ne sais pas si on gardera cette
> possibilite de demand-paging dans le noyau.
>
>   
>> Mais ! Comment faire pour allouer des pages physique alignée pour le dma
>> par exemple ?
>> Les périphérique PCI ? La mémoire vidéo (Si on change de framebuffer par
>> défaut)
>> De plus, on ne peut pas allouer n'importe quel endroit de la ram !
>> Dans le cas du DMA, c'est en dessous des 16 mo...
>>     
>
> Tu mets le doigt sur un aspect delicat de SOS : veut-on faire simple ou
> "qui marche a tous les coups" ?
>
> Dans l'article sur la mem physique, on a signalé comment ça marchait
> dans Linux (vrai allocateur d'intervalles confondu avec l'alloc
> d'intervalles virtuels car identity mapping + notion de zones classées
> par priorité). Eh bien dans SOS on s'est posé la question de savoir si
> il fallait suivre une demarche similaire, à savoir avoir un allocateur
> de memoire physique capable de gerer des intervalles de memoire
> physique, et eventuellement les regrouper dans des zones (ISA DMA, ...).
> Dans le cadre de SOS, la question qui s'est posée était donc la suivante
> : est-ce que ca ne va pas porter a confusion d'avoir 2 mecanismes
> quasiment identiques (un allocateur d'intervalles pour la RAM, un autre
> pour la VMM) ?... Par exemple, sous Linux cette confusion n'existe pas :
> la VMM noyau est un identity mapping de la RAM < 1GB. Donc dans SOS on
> se serait retrouves avec un OS "Simple" plus délicat à expliquer (risque
> de confusion) qu'un "vrai" OS qui marche et fait le café... Un comble !
> C'est en gros pourquoi on a choisi de se passer d'un allocateur de
> memoire physique digne de ce nom.
>
> Cependant, avec le recul, cette solution ne me satisfait qu'a moitié.
> Donc un "vrai" allocateur de memoire physique est dans notre TODO,
> probable que ce soit mis en oeuvre dans une prochaine iteration de SOS.
> En attendant, dans l'iteration de SOS en cours, on n'a pas besoin d'un
> tel allocateur. En effet, le seul peripherique "externe" que nous
> utilisons (une carte PCI reseau RTL8029) est attaqué par le bus I/O en
> PIO, pas par son mapping sur le bus de memoire physique, encore moins
> par acces DMA.
>
> Pour une utilisation de SOS grandeur nature, soit il faudra revoir
> l'allocateur de mem physique (alloc intervalles + eventuellement notion
> de zones avec priorites d'allocation). Soit on se restreindra seulement
> au support de certains peripheriques PCI "evolués" : de plus en plus de
> peripheriques PCI permettent en effet le DMA en mode "scatter-gather",
> ce qui signifie qu'ils sont capables d'eclater le DMA sur plusieurs
> pages non contigües ; pour ces periph, plus besoin donc de se soucier de
> pages contiguës en RAM ! Ce n'est pas le cas de la RTL8029, d'où le
> choix de l'acces en PIO. Ou alors, pour les plus fous, il faudra
> regarder du cote d'un portage sur amd64 pour l'utilisation du MMIO (si
> adapté ...) qui, semble-t'il, rend ce scatter-gather possible meme pour
> les peripheriques PCI qui ne le supportent pas (a confirmer par ceux qui
> connaissent).
>
>   
>> Pour le cas ou la ram physique est déjà utiliser, le gestionnaire de
>> mémoire virtuelle peut s'en occuper.
>> En effet, il peut allouer des pages physique ailleur dans la mémoire,
>> recopier dedans la page à libérer,
>> et "déplacer" la page de mémoire paginée dessus. SOS le fait très bien
>> dans un exemple.
>>     
>
> Tout à fait. D'ailleurs nous avons présenté une démonstration "amusante"
> de ce petit jeu dans le premier article sur la VMM. On deplaçait la page
> de code noyau en cours d'exécution sur une autre page physique.
>
>   
>> Mais une question : Comment le gestionnaire de mémoire virtuelle fait
>> pour allouer
>> des pages physique "ailleur" ? On doit donc ajouter une méthode dans
>> notre gestionnaire de mémoire
>> physique, qui permet de définir une adresse minimum d'allocation...
>> (Dite moi si je me trompe)
>>     
>
> Non, il n'y a pas de probleme a ce niveau là. La fonction
> sos_physmem_ref_physpage_at() fait le boulot.
>
> Le problème est plutôt que le déplacement de données en mémoire physique
> dont il vient d'être question, n'est valable que pour les donées
> appartenant au noyau ! Il est hors de question de déplacer n'importe
> quelle page physique utilisée en mode user ! En effet, imaginons qu'une
> page physique "Phys" soit partagée par deux processus P1 et P2. Au
> niveau du noyau, je sais que "Phys" est référencée 2 fois, mais je ne
> sais pas dans quels espaces d'adressages (pas de "reverse-mapping" dans
> SOS, cf plus bas!). Si je voulais déplacer les données de "Phys" vers
> une autre page physique, il faudrait que je retrouve quels processus la
> mappent, à quelles adresses virtuelles, que je modifie les tables de
> traduction de ces processus... c'est beaucoup trop loooooooourd !
>
> Par contre, il est 2 cas simples où je peux déplacer des données
> librement en mémoire physique : ces données ne sont utilisées que par le
> noyau (on en a fait la démonstration !), ou ces données ne sont mappées
> que par un processus user qu'on connaît.
>
> Bref, tout cela pour dire que le déplacement en mémoire physique est
> possible et pratique dans certains cas. Mais pas adapté au cas général.
> C'est pousquoi, pour le cas général, on a deux solutions : 1/ *prévenir*
> en privilégiant les allocations de mémoire physique dans des zones qui
> sont neutres vis à vis du matériel (ie adresses au delà du 16MB du DMA
> ISA par exemple), ceci nécessite un allocateur par intervalles + un
> classement par zones d'allocation clasées par priorité ; 2/ *guérir*
> avec les outils adaptés pour être capable de déplacer les pages
> physiques dans tous les cas, ceci nécessite un allocateur par
> intervalles + un mécanisme de reverse-mapping (cf plus bas).
>
>   
>> Bien, maintenant que l'allocation physique d'une zone mémoire n'est plus
>> un problème, comment allouer
>> des pages physiques alignée ???
>>     
>
> Jimagine que tu veux parler de pages physiques "contiguës" plutot que
> "alignées" ? Cf supra : dans l'itération de SOS en cours ce n'est pas
> possible car pas nécessaire pour nos besoins.
>
>   
>> Ah puis autre chose... J'ai lut qu'il faut gérer une correspondance
>> adresse physique - linéaire (virtuelle).
>> Donc, gérer l'inverse de la MMU.
>> Mais pour quel raison ? J'ai pas d'idée en tête.
>>     
>
> C'est ce qu'on appelle le "reverse-mapping". Ca permet de savoir quelles
> tables de traduction doivent être mises à jour quand on fait des choses
> avec la memoire physique. Je vois deux cas dans lesquels ça peut servir.
>
> Le premier cas a ete presente plus haut : on veut deplacer les données
> d'une page physique vers une autre, il faudra donc modifier les tables
> de traduction de tous les processus qui mappent ces données. Le
> reverse-mapping permettra de savoir exactement quelles tables sont à
> modifier et comment. Pas de reverse mapping dans SOS, en revanche il y
> en a un dans KOS.
>
> Le deuxieme cas (plus classique) concerne le page-out (p.ex swap) : on
> veut virer une page de memoire physique sur le disque, il faut donc
> savoir quelles tables de traduction sont a modifier pour leur indiquer
> que la page est maintenant sur disque. Dans ce cas, le reverse-mapping
> est interessant (en gros : gain en efficacité) mais pas necessaire. Par
> exemple, dans Linux 2.6 le reverse mapping permet d'accelerer le
> page-out. Il n'y en avait pas dans les versions precedentes du noyau, le
> page-out restait quand meme possible, mais etait moins efficace (si on
> va jusqu'au page-out dans SOS, on utilisera cette technique qui sera
> donc detaillée).
>
> Le probleme est que le reverse-mapping necessite d'allouer des donnees
> supplementaires en... memoire, donc "gaspille" de l'espace noyau.
>
>   
>> Mon premier (et pas le dernier ;) ) message sur la liste SOS !
>>     
>
> Désolé pour le retard. Quelques problèmes d'emploi du temps et de
> motivation sont à l'origine de ce retard a l'allumage...
>
> Bonne journée,
>
>