> 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.
> D'abord, pour ta curiosité : en pratique, il y a la bibliothèque libhurd-mm
Quoiqu'il en soit, le programme est toujours dépendant de la gestion mémoire de hurd est c'est incontournable. 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.
> Je pense que Marcus a donné un excellent exemple de ce qu'une gestion des ressources décentralisée et contractualisée peut permettre (son + gravure).
Mouaiff. Pour le son et la gravure, des posibilités d'autoriser un quota pour locker la mémoire sont possibles depuis Linux 2.6.8. La quantité disponible est paramétrable avec ulimit. C'est actuellement peut utilisé car peu critique. gnupg l'utilise pour éviter que les mots de passe soit en swap (par défaut une appli peut locker 8k).
Si on veut plus de souplesse, on peut passer par pam et utiliser un système type console-helper pour fixer le "ulimit" qui va bien.
> Pour les applications multimédia assez spécifiques - mais grandement utilisées, j'en utilise moi-même -, les systèmes conventionnels sont très mal adaptés : en particulier, la gestion du swap amène à des catastrophes telle l'interruption d'un stream, ce qui va casser tout ton montage ou tout ton calcul.
J'enregistre la TV avec mon PC tout en fesant d'autres choses. Avant de lancer mencoder, je change le scheduler et ulimit (pour mlockall). mencoder n'a pas de droit root (seul le programme qui change le scheduler et ulimit l'a et il est ridiculement petit).
Ainsi, je fais ce que je veux et ça enregistre sans accro.
Ceci a des limites et Hurd a aussi cette limite. J'ai un athlon 1700 et ça passe. Mais si j'avais deux cartes TV et voulais enregistrer deux chaines en même temps, ça ne peut pas passer et mon système serait inutilisable (tout le temps cpu serait affecté à mencoder).
Enfin pour des raisons de sécurité on ne peut pas laisser n'importe quel programme demander un scheduler temps réel ou de locker la mémoire. C'est valable pour tous les OS.
> Avoir un seul système pour toutes les utilisations (dans un certain rang : tout système qui a une MMU par exemple) devrait être notre but,
Jusqu'à maintenant Linux y réussi très bien.
> on sait très bien qu'un SGDB ... il n'y ait plus de mémoire virtuelle (et là, OOM killer!)
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é.
Un bon SGDB comme PostgreSQL ne fait pas de malloc() côté serveur. Donc il n'a pas ce problème de "OOM killer"). Fais un strace sur postgresql si tu en doutes.
L'arrivée de Xen peut fournir encore plus de souplesse sans perte de performance.
> ou alors se réserver juste un quota de temps CPU suffisant aux opérations classiques
Si chaque appli peut se réserver un quota de temps CPU, on va assurément à un clash. C'est pour celà que pour demander les scheduler temps réel de Linux il faut être root.
> les améliorations sur un SGDBR étaient d'environ 40, 45%.
Tu as la source ?
Ce qui me gène beaucoup avec ton type de commentaire c'est :
1- on ne comprend pas tout (je suis peut-être trop con)
2- il y a des omissions lourdes
Dire que n'importe quelle applis peut choisir sa gestion vm ou son scheduler est garantir un énorme de sécurité (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.
[^] # Re: Mouai
Posté par fabb . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 2.
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.
> D'abord, pour ta curiosité : en pratique, il y a la bibliothèque libhurd-mm
Quoiqu'il en soit, le programme est toujours dépendant de la gestion mémoire de hurd est c'est incontournable. 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.
> Je pense que Marcus a donné un excellent exemple de ce qu'une gestion des ressources décentralisée et contractualisée peut permettre (son + gravure).
Mouaiff. Pour le son et la gravure, des posibilités d'autoriser un quota pour locker la mémoire sont possibles depuis Linux 2.6.8. La quantité disponible est paramétrable avec ulimit. C'est actuellement peut utilisé car peu critique. gnupg l'utilise pour éviter que les mots de passe soit en swap (par défaut une appli peut locker 8k).
Si on veut plus de souplesse, on peut passer par pam et utiliser un système type console-helper pour fixer le "ulimit" qui va bien.
> Pour les applications multimédia assez spécifiques - mais grandement utilisées, j'en utilise moi-même -, les systèmes conventionnels sont très mal adaptés : en particulier, la gestion du swap amène à des catastrophes telle l'interruption d'un stream, ce qui va casser tout ton montage ou tout ton calcul.
J'enregistre la TV avec mon PC tout en fesant d'autres choses. Avant de lancer mencoder, je change le scheduler et ulimit (pour mlockall). mencoder n'a pas de droit root (seul le programme qui change le scheduler et ulimit l'a et il est ridiculement petit).
Ainsi, je fais ce que je veux et ça enregistre sans accro.
Ceci a des limites et Hurd a aussi cette limite. J'ai un athlon 1700 et ça passe. Mais si j'avais deux cartes TV et voulais enregistrer deux chaines en même temps, ça ne peut pas passer et mon système serait inutilisable (tout le temps cpu serait affecté à mencoder).
Enfin pour des raisons de sécurité on ne peut pas laisser n'importe quel programme demander un scheduler temps réel ou de locker la mémoire. C'est valable pour tous les OS.
> Avoir un seul système pour toutes les utilisations (dans un certain rang : tout système qui a une MMU par exemple) devrait être notre but,
Jusqu'à maintenant Linux y réussi très bien.
> on sait très bien qu'un SGDB ... il n'y ait plus de mémoire virtuelle (et là, OOM killer!)
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é.
Un bon SGDB comme PostgreSQL ne fait pas de malloc() côté serveur. Donc il n'a pas ce problème de "OOM killer"). Fais un strace sur postgresql si tu en doutes.
L'arrivée de Xen peut fournir encore plus de souplesse sans perte de performance.
> ou alors se réserver juste un quota de temps CPU suffisant aux opérations classiques
Si chaque appli peut se réserver un quota de temps CPU, on va assurément à un clash. C'est pour celà que pour demander les scheduler temps réel de Linux il faut être root.
> les améliorations sur un SGDBR étaient d'environ 40, 45%.
Tu as la source ?
Ce qui me gène beaucoup avec ton type de commentaire c'est :
1- on ne comprend pas tout (je suis peut-être trop con)
2- il y a des omissions lourdes
Dire que n'importe quelle applis peut choisir sa gestion vm ou son scheduler est garantir un énorme de sécurité (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.