Gamin ? Gamin, c'était pour rire !

On Wed, 21 Sep 2005 23:42:46 +0000, Nicolas George wrote:

l'indien wrote in message <pan.2005.09.21.22.03.49.423452@magic.fr>:

C'est vrai mais il est peut être aussi interressant que le temps passé
dans le noyau est assez souvent pénalisant pour tout le monde vu qu'il
est souvent obligé de locker des structures, ...

Oui, il y a plein de trucs, mais tu n'en sors pas : tout ce que doit faire
le noyau pour passer un message à un processus, quelqu'un doit le faire,
d'une manière ou d'une autre pour passer des messages d'un processus. On
n'en sort pas, le noyau est mieux placé pour passer ces messages.

On en revient aux bonnes vieilles batailles: qu'est ce que le noyau doit
faire et qu'est ce qu'il doit déleguer à des process. Je n'irai pas
jusqu'à dire qu'il faut faire des micro-noyaux, mais il y a quand même
des bonnes idée, là dedans...

Alors que si un process est blocqué, il est préempté.

Un noyau bien conçu est capable de se préempter lui-même. Ok, Linux n'est
pas un noyau bien conçu, mais il s'en approche.

La préemption du noyau Linux reste assez périlleuse, d'après mes
(mauvaises) expériences... Et ça ne résoud pas le problème des locks.
Si un sous-système est locké, ça bloque tous les process qui en ont
besoin...

C'est vrai que sur x86 un switch de contexte est très couteux (c'est
moins vrai sur les amd64), mais comme la plupart des CPU n'ont pas ce
problème et que le x86 est loin de représenter la majorité des CPU
vendus, je pense qu'il ne faut pas trop s'atarder sur les tares de cette
architecture.

D'un autre côté, le x86 reste ultra-majoritaire dans la catégorie des
processeurs sur lesquels on fait tourner des trucs style Nautilus ou
Konqueror qui ont besoin de fam ou assimilé.

C'est très utile en embarqué aussi, figure toi. Et là, le x86 est ultra
minoritaire. C'est même plutôt une architecture fantôme, dans ce
domaine...

Bon, ça commence à sentir fortement le troll roussi, par ici, non ?

Oui, c'est bien, ça passe le temps.

Vu comme ça, je prends ça comme un encouragement ;-)

Il suffit de mapper un espace partagé en mémoire, un fichier, par
exemple. Un process écrit, les autres lisent, il n'y a aucune recopie
mémoire.

Mais ce n'est pas parfait. Il n'est pas possible d'obtenir un mapping
anonyme partagé entre deux processus à moins de le mettre en place dans un
ancêtre commun. C'est assez naze, d'ailleurs. J'ai vu passer un patch pour
faire l'inverse d'un mmap, c'est à dire obtenir un fd pointant vers une zône
de mémoire, fd qu'on pouvait ensuite passer sur une socket locale, mais il
n'y a eu aucune suite. À défaut de mapping anonyme, il faut, comme tu le
suggères, le mapping d'un fichier. Mais là, ça veut dire qu'on se tape la
surcharge du filesystem, et même avec un tmpfs, ça doit quand même coûter
pas mal. Tout ceci n'est vraiment pas satisfaisant.

C'est possible en mappant /dev/mem et en se débrouillant pour passer
l'addresse à mapper aux process qui en ont besoin. C'est vrai que ça
ressemble fortement à un hack...
Sinon, il faut créer un ramdisk sans filesystem et le mapper. Dans ce
cas, il n'y a pas d'overhead de filesystem et tout le monde travaille dans
le cache. L'effet secondaire, c'est que les pages en question ne pourront
pas être swappées, ce qui peut être génant...

En fait, j'ai travaillé récement sur un sujet se rapprochant de ce
problème: j'ai écrit un device de style ethernet pour communiquer entre
un PC et un processeur embarqué sur une carte PCI et qui utilise
simplement l'accès des devices PCI à la mémoire principale (l'inverse
marche aussi très bien).
En utilisant la même méthode (très simple, en fait), il suffirait
d'ajouter un pseudo-device pour pouvoir mapper des pools de buffers
partagés entre des process. Et ça donne une interface bi-directionnelle,
au besoin.
Ce serait une solution assez élegante, en fait, qui donnerait une
interface de type MPI entre des process. Ca m'amuse. Ca n'est peut être
pas utile, mais je vais regarder si je peut faire quelque chose comme
celà...
Le seul point délicat, c'est qu'il vaut mieux mapper les pages en
question dans l'espace d'un des process (celui qui écrit, à priori) et
non dans celui du kernel, si on veut qu'elles soient swapables. Dans le
cas de mon pseudo-device ethernet, les buffers sont vmalloc'ées.
Pour l'utiliser, ce serait très simple: tu ouvres le device, et tu fait
un select pour savoir s'il y a des choses à lire.
On peut rajouter des ioctl pour mettre des token et pouvoir ainsi créer
un nombre virtuellement infini d'espaces partagés.
Avec une méthode de ce genre, l'overhead serait extrèmement faible:
il suffirait de faire un ioctl pour obtenir l'addresse et la taille du
message suivant. Si on ne veut pas de recopie de buffer, le read/write n'a
pas trop de sens.

l'indien wrote in message <pan.2005.09.22.07.02.18.769194@magic.fr>:

Je n'irai pas
jusqu'à dire qu'il faut faire des micro-noyaux

Oh, moi je n'hésite pas à le dire : il faut faire des micro-noyaux.
Peut-être pas partout, mais pour les machines domestiques, les stations de
travail et les serveurs (par opposition, probablement, à l'embarqué),
clairement oui. Après tout, si Minix était assez fluide pour qu'on ait envie
de l'utiliser sur des 386 et moins, avec les monstres qu'on a actuellement,
on ne devrait voir aucune différence.

Après, il est probable que l'API Unix ne soit pas vraiment adaptée à tirer
le meilleur partie d'une organisation en micro-noyau.

Mais dans un micro-noyau, la question ne se pose pas, puisque le filesystem
est lui-même déjà en processus userland. Là, on a le filesystem dans le
noyau. Mais dans un cas comme dans l'autre, le message doit à la base partir
du filesystem. Le noyau doit donc avoir le nécessaire pour notifier un
processus.

La préemption du noyau Linux reste assez périlleuse, d'après mes
(mauvaises) expériences... Et ça ne résoud pas le problème des locks.
Si un sous-système est locké, ça bloque tous les process qui en ont
besoin...

Oui, mais il n'y a pas de raison qu'il faille locker plus de sous-systèmes
pour un message de noyau à processus que pour un message de processus à
processus.

C'est très utile en embarqué aussi, figure toi.

J'ai du mal à voir pour quoi faire.

C'est possible en mappant /dev/mem et en se débrouillant pour passer
l'addresse à mapper aux process qui en ont besoin. C'est vrai que ça
ressemble fortement à un hack...
Sinon, il faut créer un ramdisk sans filesystem et le mapper. Dans ce
cas, il n'y a pas d'overhead de filesystem et tout le monde travaille dans
le cache. L'effet secondaire, c'est que les pages en question ne pourront
pas être swappées, ce qui peut être génant...
<snip>

Tout ceci fonctionne à peu de coût, effectivement, mais ça a un gros
défaut : ce n'est pas partageable. On ne peut pas autoriser n'importe quel
utilisateur à se créer un ramdisk, et si on crée un unique ramdisk qu'on met
en accès public, il n'y a aucun moyen d'en compartimenter l'usage. Idem pour
/dev/mem. Tout ceci demande énormément d'intervention de root, et une grande
confiance en les utilisateurs du système.

Pour un système assez souple, comme on le souhaite pour un Unix
multi-utilisateurs généraliste, la solution qui permettrait à un processus
de passer un bout de son espace d'adressage à un autre via une socket me
semblerait vraiment idéale. Dommage qu'elle n'ait pas été retenue.

Pour l'utiliser, ce serait très simple: tu ouvres le device, et tu fait
un select pour savoir s'il y a des choses à lire.

J'allais proposer un futex. Mais je me rends compte que ça a un gros
défaut : ça ne s'intègre pas du tout au système de multiplexage des IPC à
base de select/poll/epoll. C'est assez naze, je trouve.