> Quant à la gestion de la mémoire, je n'imagine pas que quelqu'un avec une grande d'expérience de la programmation puisse penser que ça ne sert à rien.
Hmmm.
Actuellement sous Linux si tu veux faire quelque chose de fin, tu alloues un gros bloque mémoire et tu fais ton taf dedans.
Cette grosse allocation mémoire ne bouffera pas de mémoire tant que tu n'écris pas dedans. Tu peux utiliser alloc pour que la mémoire soit réellement allouée.
Ce n'est pas la même chose dont manuel parlait. Là, tu parles de comment un processus va gérer son espace d'addressage virtuel, et là, bien sûr, il peut faire ce qu'il veut que ce soit sous GNU/Linux ou GNU/Hurd.
Ce dont manuel parlait, c'est de la gestion de la mémoire physique. L'exemple le plus simple, c'est "quelle page swapper". Sans même aller chercher loin (les méchanismes de négociation de ressources), considérons juste un système qui au lieu de swapper une page en essayant de déterminer comme il peut (LRU, aging, ...) laquelle est la moins utilisée, va demander à l'application "désigne une page, et elle sera swappée". Pas de compromission de sécurité là-dedans, le système choisi toujours dans quelle application la page est prise, mais l'application choisi laquelle, avec les connaissances qu'elle a sur les données, et que le système ne peut pas avoir. Variante: l'application dit au système "ces pages là je veux pas les swapper, si jamais t'as envie d'en swapper une, je t'offre ces pages là à la place" (ce que l'on nomme pages de compensation). Ce genre de méchanisme peuvent grandement améliorer l'efficacité dans certaines conditions.
On peut aussi, sous GNU/Hurd (et même sous Mach, pour ça), parfaitement envisager différents niveaux de swap: compressé en mémoire (on se contente de compresser les pages sans les envoyer sur le disque), sur le disque, sur le réseau, compressées sur le disque, compressées sur le réseau, ... l'application pouvant choisir, suivant le type de données (bon taux de compression ou non, est-ce qu'on risque d'en avoir besoin ou non, ...), quel "swap" utiliser pour quelle page.
Je ne vois pas par quel miracle un programme pourrait imposer sa gestion mémoire à l'OS. Hurd gère le swap, je ne comprend pas comment plusieur applis à la fois pourrait gérer le swap sans tout faire exploser.
Bof. Avec Linux, si ton système héberge un SGDB ou des applis critiquent, tu peux configurer la vm pour qu'un malloc soit "garanti". C'est à dire que si le malloc ne retourne pas NULL, la mémoire sera utilisable (pas de segfault ni de OOM killer). Le problème c'est que ça bouffe beaucoup de mémoire et en général c'est désactivé.
La question n'est pas là, la question un SGBDR qui va s'adapter, en troquant temps CPU (lookup) contre mémoire (cache) suivant les disponibilités des deux dans le système. Ce dont tu parles, c'est d'éviter les OOM-kill lorsque la swap est pleine, mais ça n'empêche en rien que le système va "trasher" (faire énormément de swap-in/swap-out) dans certaines situations. Ou qu'un programme va faire un abort() vu que son malloc a renvoyé NULL et qu'il ne peut plus s'en sortir.
Un bon SGDB comme PostgreSQL ne fait pas de malloc() côté serveur. Donc il n'a pas ce problème de "OOM killer"
malloc n'est pas un appel système, malloc repose sur brk/sbrk et mmap. PostgreSQL utilise au moins l'un des deux (probablement mmap, peut-être les deux) et est donc tout autant vulnérable au OOM-kill que n'importe quelle autre application.
Dire que n'importe quelle applis peut choisir sa gestion vm ou son scheduler est garantir un énorme de sécurité (DOS).
J'ai donné deux exemples simples pour le mémoire, qui n'ouvrent la porte à un aucun DoS.
Puisque les resources sont limitées, c'est à l'OS (un élément central) de distributer, d'arbitrer les demandes de ressources et non aux applis. Sinon n'importe quelle application peut tout faire exploser.
Pour le CPU, on peut par exemple concevoir un système où le temps CPU est réparti non entre processus, mais entre utilisateurs (avec des règles données par l'administrateur système), et où chaque utilisateur peut lui gérer comme il le souhaite le temps CPU pour ses propres applications (par exemple, son xmms sera prioritaire sur ses gcc et son firefox, de la manière qu'un processus RT l'est sous Linux, mais uniquement vis à vis du temps de l'utilisateur). Après, on peut concevoir des systèmes encore plus poussés, à base de contrats par exemple: le système "vend" à xmms un contrat valable 5 minutes pour avoir, de manière sûre, 10ms de temps CPU toutes les secondes. Le prix de cette "vente" dépendra de la charge de la machine. Au bout de 5 minutes, xmms devra renégocier le contrat. Si la charge de la machine est plus élevée, il ne pourra peut-être pas le payer, mais en général accorder un temps garanti d'1% à une application est parfaitement possible, même quand le système est chargé (grosse compilation, ...). Les possibilités offertes sont nombreuses, et l'un des avantages majeurs des systèmes à base de micronoyau est que l'on peut facilement développer une solution adaptée à la situation exacte (ou modifier une solution existante).
Pour finir, une petite ouverture du sujet: c'est ça aussi, rendre la liberté aux utilisateurs (le but du projet GNU). Comme en politique d'ailleurs. Il y a la liberté légale (la licence l'autorise), qui ne peut être que théorique non praticable, et la liberté garantie (la licence l'autorise et le système le rend possible). C'est toute la différence entre "droit de chercher un emploi" (et sa variante "droit de travailler") et "droit d'obtenir un emploi" (et sa variante "droit au travail") par exemple, mais c'est un autre débat ;)
[^] # Re: Mouai
Posté par Gaël Le Mignot . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 10.
Ce n'est pas la même chose dont manuel parlait. Là, tu parles de comment un processus va gérer son espace d'addressage virtuel, et là, bien sûr, il peut faire ce qu'il veut que ce soit sous GNU/Linux ou GNU/Hurd.
Ce dont manuel parlait, c'est de la gestion de la mémoire physique. L'exemple le plus simple, c'est "quelle page swapper". Sans même aller chercher loin (les méchanismes de négociation de ressources), considérons juste un système qui au lieu de swapper une page en essayant de déterminer comme il peut (LRU, aging, ...) laquelle est la moins utilisée, va demander à l'application "désigne une page, et elle sera swappée". Pas de compromission de sécurité là-dedans, le système choisi toujours dans quelle application la page est prise, mais l'application choisi laquelle, avec les connaissances qu'elle a sur les données, et que le système ne peut pas avoir. Variante: l'application dit au système "ces pages là je veux pas les swapper, si jamais t'as envie d'en swapper une, je t'offre ces pages là à la place" (ce que l'on nomme pages de compensation). Ce genre de méchanisme peuvent grandement améliorer l'efficacité dans certaines conditions.
On peut aussi, sous GNU/Hurd (et même sous Mach, pour ça), parfaitement envisager différents niveaux de swap: compressé en mémoire (on se contente de compresser les pages sans les envoyer sur le disque), sur le disque, sur le réseau, compressées sur le disque, compressées sur le réseau, ... l'application pouvant choisir, suivant le type de données (bon taux de compression ou non, est-ce qu'on risque d'en avoir besoin ou non, ...), quel "swap" utiliser pour quelle page.
Je t'ai donné deux exemples simples de possibilités de gestion évoluée de la mémoire, si tu veux des exemples plus poussés, tu peux lire http://l4ka.org/publications/paper.php?docid=659(...) par exemple.
La question n'est pas là, la question un SGBDR qui va s'adapter, en troquant temps CPU (lookup) contre mémoire (cache) suivant les disponibilités des deux dans le système. Ce dont tu parles, c'est d'éviter les OOM-kill lorsque la swap est pleine, mais ça n'empêche en rien que le système va "trasher" (faire énormément de swap-in/swap-out) dans certaines situations. Ou qu'un programme va faire un abort() vu que son malloc a renvoyé NULL et qu'il ne peut plus s'en sortir.
malloc n'est pas un appel système, malloc repose sur brk/sbrk et mmap. PostgreSQL utilise au moins l'un des deux (probablement mmap, peut-être les deux) et est donc tout autant vulnérable au OOM-kill que n'importe quelle autre application.
J'ai donné deux exemples simples pour le mémoire, qui n'ouvrent la porte à un aucun DoS.
Pour le CPU, on peut par exemple concevoir un système où le temps CPU est réparti non entre processus, mais entre utilisateurs (avec des règles données par l'administrateur système), et où chaque utilisateur peut lui gérer comme il le souhaite le temps CPU pour ses propres applications (par exemple, son xmms sera prioritaire sur ses gcc et son firefox, de la manière qu'un processus RT l'est sous Linux, mais uniquement vis à vis du temps de l'utilisateur). Après, on peut concevoir des systèmes encore plus poussés, à base de contrats par exemple: le système "vend" à xmms un contrat valable 5 minutes pour avoir, de manière sûre, 10ms de temps CPU toutes les secondes. Le prix de cette "vente" dépendra de la charge de la machine. Au bout de 5 minutes, xmms devra renégocier le contrat. Si la charge de la machine est plus élevée, il ne pourra peut-être pas le payer, mais en général accorder un temps garanti d'1% à une application est parfaitement possible, même quand le système est chargé (grosse compilation, ...). Les possibilités offertes sont nombreuses, et l'un des avantages majeurs des systèmes à base de micronoyau est que l'on peut facilement développer une solution adaptée à la situation exacte (ou modifier une solution existante).
Pour finir, une petite ouverture du sujet: c'est ça aussi, rendre la liberté aux utilisateurs (le but du projet GNU). Comme en politique d'ailleurs. Il y a la liberté légale (la licence l'autorise), qui ne peut être que théorique non praticable, et la liberté garantie (la licence l'autorise et le système le rend possible). C'est toute la différence entre "droit de chercher un emploi" (et sa variante "droit de travailler") et "droit d'obtenir un emploi" (et sa variante "droit au travail") par exemple, mais c'est un autre débat ;)