C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon alors qu'il aurait fallu n messages si chaque appli le faisait par elle-même. Ca évite donc de surcharger le noyau et confie le problème du dispatch des messages à un démon, ce qui économise le précieux temps machine utilisé par le noyau.
Euh, tu pipotes à fond, là. Pour la communication entre le démon et les processus, il faut passer par le noyau, on n'y coupe pas, et plutôt deux fois qu'une (un appel système pour envoyer le message, un appel système pour le recevoir).
l'indien wrote in message <pan.2005.09.20.21.31.34.860026@magic.fr>:
C'est surtout que ça limite la communication avec le noyau: si n process
veulent surveiller un fichier ou un répertoire, il suffit d'un message du
noyau vers le mode user avec un démon alors qu'il aurait fallu n messages
si chaque appli le faisait par elle-même. Ca évite donc de surcharger le
noyau et confie le problème du dispatch des messages à un démon, ce qui
économise le précieux temps machine utilisé par le noyau.
Euh, tu pipotes à fond, là. Pour la communication entre le démon et les
processus, il faut passer par le noyau, on n'y coupe pas, et plutôt deux
fois qu'une (un appel système pour envoyer le message, un appel système pour
le recevoir).
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon alors qu'il aurait fallu n messages si chaque appli le faisait par elle-même. Ca évite donc de surcharger le noyau et confie le problème du dispatch des messages à un démon, ce qui économise le précieux temps machine utilisé par le noyau.
Euh, tu pipotes à fond, là. Pour la communication entre le démon et les processus, il faut passer par le noyau, on n'y coupe pas, et plutôt deux fois qu'une (un appel système pour envoyer le message, un appel système pour le recevoir).
lhabert
l'indien :
Je n'ai pas regardé les dernières versions, mais à priori les notifications sont fait par des messages, pas par des signaux.
Qu'entends tu pas « message » ? Le machin à la noix dans les sysV IPC? De toutes manières, ça n'est pas ça. Si tu regardes la page de man de fcntl, tu verras :
F_NOTIFY [snip] Notification occurs via delivery of a signal.
C'est la même approche qui est utilisée dans la couche réseau et je ne pense pas qu'ils aient envie de revenir aux signaux.
Rien compris.
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon
Qui doit répercuter vers ses n clients, ce pour quoi il doit passer par le noyau aussi. Ça doit pas changer grand chose.
l'indien :
Je n'ai pas regardé les dernières versions, mais à priori les
notifications sont fait par des messages, pas par des signaux.
Qu'entends tu pas « message » ? Le machin à la noix dans les sysV IPC? De
toutes manières, ça n'est pas ça. Si tu regardes la page de man de fcntl, tu
verras :
F_NOTIFY
[snip]
Notification occurs via delivery of a signal.
C'est la même approche qui est utilisée dans la couche réseau et je ne
pense pas qu'ils aient envie de revenir aux signaux.
Rien compris.
C'est surtout que ça limite la communication avec le noyau: si n process
veulent surveiller un fichier ou un répertoire, il suffit d'un message du
noyau vers le mode user avec un démon
Qui doit répercuter vers ses n clients, ce pour quoi il doit passer par le
noyau aussi. Ça doit pas changer grand chose.
Je n'ai pas regardé les dernières versions, mais à priori les notifications sont fait par des messages, pas par des signaux.
Qu'entends tu pas « message » ? Le machin à la noix dans les sysV IPC? De toutes manières, ça n'est pas ça. Si tu regardes la page de man de fcntl, tu verras :
F_NOTIFY [snip] Notification occurs via delivery of a signal.
C'est la même approche qui est utilisée dans la couche réseau et je ne pense pas qu'ils aient envie de revenir aux signaux.
Rien compris.
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon
Qui doit répercuter vers ses n clients, ce pour quoi il doit passer par le noyau aussi. Ça doit pas changer grand chose.
l'indien
On Tue, 20 Sep 2005 21:44:25 +0000, Nicolas George wrote:
l'indien wrote in message :
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon alors qu'il aurait fallu n messages si chaque appli le faisait par elle-même. Ca évite donc de surcharger le noyau et confie le problème du dispatch des messages à un démon, ce qui économise le précieux temps machine utilisé par le noyau.
Euh, tu pipotes à fond, là. Pour la communication entre le démon et les processus, il faut passer par le noyau, on n'y coupe pas, et plutôt deux fois qu'une (un appel système pour envoyer le message, un appel système pour le recevoir).
La communication entre 2 process peut être infiniment moins couteuse que la création de messages par le noyau. Dans le cas du passage de message entre 2 process, il y a effectivement 2 syscall mais le travail du noyau (si le code est bien fait) se résume à marquer la page contenant le message comme partagée entre les 2 process. Dans le cas de la génération du message, il faut allouer une page, générer le message, la "donner" à tous les process susceptible de recevoir le message et la garder mappée tant que ceux ci n'ont pas tous reçu le message. Ca fait moins d'appels systèmes mais ça complique le code du noyau et ça rend ce code moins efficace. Sans compter le fait que ça fait écrire du code compliqué dédié à cette tâche tandis que dans l'autre cas, c'est du code générique qui sert pour délivrer les messages.
On Tue, 20 Sep 2005 21:44:25 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.09.20.21.31.34.860026@magic.fr>:
C'est surtout que ça limite la communication avec le noyau: si n process
veulent surveiller un fichier ou un répertoire, il suffit d'un message du
noyau vers le mode user avec un démon alors qu'il aurait fallu n messages
si chaque appli le faisait par elle-même. Ca évite donc de surcharger le
noyau et confie le problème du dispatch des messages à un démon, ce qui
économise le précieux temps machine utilisé par le noyau.
Euh, tu pipotes à fond, là. Pour la communication entre le démon et les
processus, il faut passer par le noyau, on n'y coupe pas, et plutôt deux
fois qu'une (un appel système pour envoyer le message, un appel système pour
le recevoir).
La communication entre 2 process peut être infiniment moins couteuse que
la création de messages par le noyau. Dans le cas du passage de message
entre 2 process, il y a effectivement 2 syscall mais le travail du noyau
(si le code est bien fait) se résume à marquer la page contenant le
message comme partagée entre les 2 process.
Dans le cas de la génération du message, il faut allouer une page,
générer le message, la "donner" à tous les process susceptible de
recevoir le message et la garder mappée tant que ceux ci n'ont pas tous
reçu le message. Ca fait moins d'appels systèmes mais ça complique le
code du noyau et ça rend ce code moins efficace. Sans compter le fait que
ça fait écrire du code compliqué dédié à cette tâche tandis que
dans l'autre cas, c'est du code générique qui sert pour délivrer les
messages.
On Tue, 20 Sep 2005 21:44:25 +0000, Nicolas George wrote:
l'indien wrote in message :
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon alors qu'il aurait fallu n messages si chaque appli le faisait par elle-même. Ca évite donc de surcharger le noyau et confie le problème du dispatch des messages à un démon, ce qui économise le précieux temps machine utilisé par le noyau.
Euh, tu pipotes à fond, là. Pour la communication entre le démon et les processus, il faut passer par le noyau, on n'y coupe pas, et plutôt deux fois qu'une (un appel système pour envoyer le message, un appel système pour le recevoir).
La communication entre 2 process peut être infiniment moins couteuse que la création de messages par le noyau. Dans le cas du passage de message entre 2 process, il y a effectivement 2 syscall mais le travail du noyau (si le code est bien fait) se résume à marquer la page contenant le message comme partagée entre les 2 process. Dans le cas de la génération du message, il faut allouer une page, générer le message, la "donner" à tous les process susceptible de recevoir le message et la garder mappée tant que ceux ci n'ont pas tous reçu le message. Ca fait moins d'appels systèmes mais ça complique le code du noyau et ça rend ce code moins efficace. Sans compter le fait que ça fait écrire du code compliqué dédié à cette tâche tandis que dans l'autre cas, c'est du code générique qui sert pour délivrer les messages.
l'indien
On Tue, 20 Sep 2005 21:54:40 +0000, Luc Habert wrote:
l'indien :
Je n'ai pas regardé les dernières versions, mais à priori les notifications sont fait par des messages, pas par des signaux.
Qu'entends tu pas « message » ? Le machin à la noix dans les sysV IPC? De toutes manières, ça n'est pas ça. Si tu regardes la page de man de fcntl, tu verras :
F_NOTIFY [snip] Notification occurs via delivery of a signal.
Effectivement. Il existait une interface par messages. J'avais fait un programme qui se servait de celà, il y a assez longtemps... Je vais essayer de le retrouver...
C'est la même approche qui est utilisée dans la couche réseau et je ne pense pas qu'ils aient envie de revenir aux signaux.
Rien compris.
Il y a tout un système de notifications d'évènements dans la couche réseau qui permet à un process de récupérer tous les changements d'états du réseau et de changer la configuration du réseau (le process peut également envoyer des messages au kernel). On peut aussi implémenter un firewall applicatif, avec cette interface, en demandant à recevoir certains paquets réseau. Dans ce cas, il n'est en fait pas possible d'utiliser des signaux car l'interface noyau/process est (et doit être) bidirectionnelle.
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon
Qui doit répercuter vers ses n clients, ce pour quoi il doit passer par le noyau aussi. Ça doit pas changer grand chose.
Il y a une sacrée différence. Voir ma réponse plus bas.
On Tue, 20 Sep 2005 21:54:40 +0000, Luc Habert wrote:
l'indien :
Je n'ai pas regardé les dernières versions, mais à priori les
notifications sont fait par des messages, pas par des signaux.
Qu'entends tu pas « message » ? Le machin à la noix dans les sysV IPC? De
toutes manières, ça n'est pas ça. Si tu regardes la page de man de fcntl, tu
verras :
F_NOTIFY
[snip]
Notification occurs via delivery of a signal.
Effectivement.
Il existait une interface par messages.
J'avais fait un programme qui se servait de celà, il y a assez longtemps...
Je vais essayer de le retrouver...
C'est la même approche qui est utilisée dans la couche réseau et je ne
pense pas qu'ils aient envie de revenir aux signaux.
Rien compris.
Il y a tout un système de notifications d'évènements dans la couche
réseau qui permet à un process de récupérer tous les changements
d'états du réseau et de changer la configuration du réseau (le process
peut également envoyer des messages au kernel).
On peut aussi implémenter un firewall applicatif, avec cette interface,
en demandant à recevoir certains paquets réseau.
Dans ce cas, il n'est en fait pas possible d'utiliser des signaux car
l'interface noyau/process est (et doit être) bidirectionnelle.
C'est surtout que ça limite la communication avec le noyau: si n process
veulent surveiller un fichier ou un répertoire, il suffit d'un message du
noyau vers le mode user avec un démon
Qui doit répercuter vers ses n clients, ce pour quoi il doit passer par le
noyau aussi. Ça doit pas changer grand chose.
Il y a une sacrée différence. Voir ma réponse plus bas.
On Tue, 20 Sep 2005 21:54:40 +0000, Luc Habert wrote:
l'indien :
Je n'ai pas regardé les dernières versions, mais à priori les notifications sont fait par des messages, pas par des signaux.
Qu'entends tu pas « message » ? Le machin à la noix dans les sysV IPC? De toutes manières, ça n'est pas ça. Si tu regardes la page de man de fcntl, tu verras :
F_NOTIFY [snip] Notification occurs via delivery of a signal.
Effectivement. Il existait une interface par messages. J'avais fait un programme qui se servait de celà, il y a assez longtemps... Je vais essayer de le retrouver...
C'est la même approche qui est utilisée dans la couche réseau et je ne pense pas qu'ils aient envie de revenir aux signaux.
Rien compris.
Il y a tout un système de notifications d'évènements dans la couche réseau qui permet à un process de récupérer tous les changements d'états du réseau et de changer la configuration du réseau (le process peut également envoyer des messages au kernel). On peut aussi implémenter un firewall applicatif, avec cette interface, en demandant à recevoir certains paquets réseau. Dans ce cas, il n'est en fait pas possible d'utiliser des signaux car l'interface noyau/process est (et doit être) bidirectionnelle.
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon
Qui doit répercuter vers ses n clients, ce pour quoi il doit passer par le noyau aussi. Ça doit pas changer grand chose.
Il y a une sacrée différence. Voir ma réponse plus bas.
lhabert
Certes tu déplace la complexité du noyau vers l'userland, mais je ne vois pas ce que ça change au niveau efficacité. Le boulot en moins qu'a à faire le noyau, il est fait par le démon.
Certes tu déplace la complexité du noyau vers l'userland, mais je ne vois
pas ce que ça change au niveau efficacité. Le boulot en moins qu'a à faire
le noyau, il est fait par le démon.
Certes tu déplace la complexité du noyau vers l'userland, mais je ne vois pas ce que ça change au niveau efficacité. Le boulot en moins qu'a à faire le noyau, il est fait par le démon.
Nicolas George
l'indien wrote in message :
La communication entre 2 process peut être infiniment moins couteuse que la création de messages par le noyau.
Il n'y a aucune raison pour qu'elle le soit : comme le signale Luc, tout ce que ne fait pas le noyau doit être fait par le processus, et ce n'est pas plus rapide pour être en userland. En outre, pour de petits messages comme il est question ici, la copie du bloc du message doit être à peu près peanuts par rapport au coût d'un changement de contexte, sur un processeur du type x86 au moins.
Dans le cas du passage de message entre 2 process, il y a effectivement 2 syscall mais le travail du noyau (si le code est bien fait) se résume à marquer la page contenant le message comme partagée entre les 2 process.
Tu penses à quel mécanisme d'IPC, là ? Je n'en connais aucun, dans Linux, qui fonctionne sur le principe du partage de page -- et pourtant j'ai cherché.
l'indien wrote in message <pan.2005.09.21.11.54.38.356494@magic.fr>:
La communication entre 2 process peut être infiniment moins couteuse que
la création de messages par le noyau.
Il n'y a aucune raison pour qu'elle le soit : comme le signale Luc, tout ce
que ne fait pas le noyau doit être fait par le processus, et ce n'est pas
plus rapide pour être en userland. En outre, pour de petits messages comme
il est question ici, la copie du bloc du message doit être à peu près
peanuts par rapport au coût d'un changement de contexte, sur un processeur
du type x86 au moins.
Dans le cas du passage de message
entre 2 process, il y a effectivement 2 syscall mais le travail du noyau
(si le code est bien fait) se résume à marquer la page contenant le
message comme partagée entre les 2 process.
Tu penses à quel mécanisme d'IPC, là ? Je n'en connais aucun, dans Linux,
qui fonctionne sur le principe du partage de page -- et pourtant j'ai
cherché.
La communication entre 2 process peut être infiniment moins couteuse que la création de messages par le noyau.
Il n'y a aucune raison pour qu'elle le soit : comme le signale Luc, tout ce que ne fait pas le noyau doit être fait par le processus, et ce n'est pas plus rapide pour être en userland. En outre, pour de petits messages comme il est question ici, la copie du bloc du message doit être à peu près peanuts par rapport au coût d'un changement de contexte, sur un processeur du type x86 au moins.
Dans le cas du passage de message entre 2 process, il y a effectivement 2 syscall mais le travail du noyau (si le code est bien fait) se résume à marquer la page contenant le message comme partagée entre les 2 process.
Tu penses à quel mécanisme d'IPC, là ? Je n'en connais aucun, dans Linux, qui fonctionne sur le principe du partage de page -- et pourtant j'ai cherché.
l'indien
On Wed, 21 Sep 2005 13:02:09 +0000, Nicolas George wrote:
l'indien wrote in message :
La communication entre 2 process peut être infiniment moins couteuse que la création de messages par le noyau.
Il n'y a aucune raison pour qu'elle le soit : comme le signale Luc, tout ce que ne fait pas le noyau doit être fait par le processus, et ce n'est pas plus rapide pour être en userland. En outre, pour de petits messages comme il est question ici, la copie du bloc du message doit être à peu près peanuts par rapport au coût d'un changement de contexte, sur un processeur du type x86 au moins.
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, ... Alors que si un process est blocqué, il est préempté. Ca joue aussi sur l'efficacité globale. 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. Il y a de toutes façon tellement de ressources gaspillée par l'architecture qu'on est vraiment plus à ça près, de nos jours.
Bon, ça commence à sentir fortement le troll roussi, par ici, non ?
entre 2 process, il y a effectivement 2 syscall mais le travail du noyau (si le code est bien fait) se résume à marquer la page contenant le message comme partagée entre les 2 process.
Tu penses à quel mécanisme d'IPC, là ? Je n'en connais aucun, dans Linux, qui fonctionne sur le principe du partage de page -- et pourtant j'ai cherché.
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.
On Wed, 21 Sep 2005 13:02:09 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.09.21.11.54.38.356494@magic.fr>:
La communication entre 2 process peut être infiniment moins couteuse que
la création de messages par le noyau.
Il n'y a aucune raison pour qu'elle le soit : comme le signale Luc, tout ce
que ne fait pas le noyau doit être fait par le processus, et ce n'est pas
plus rapide pour être en userland. En outre, pour de petits messages comme
il est question ici, la copie du bloc du message doit être à peu près
peanuts par rapport au coût d'un changement de contexte, sur un processeur
du type x86 au moins.
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, ...
Alors que si un process est blocqué, il est préempté.
Ca joue aussi sur l'efficacité globale.
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. Il y a de toutes façon tellement de ressources gaspillée
par l'architecture qu'on est vraiment plus à ça près, de nos jours.
Bon, ça commence à sentir fortement le troll roussi, par ici, non ?
entre 2 process, il y a effectivement 2 syscall mais le travail du noyau
(si le code est bien fait) se résume à marquer la page contenant le
message comme partagée entre les 2 process.
Tu penses à quel mécanisme d'IPC, là ? Je n'en connais aucun, dans Linux,
qui fonctionne sur le principe du partage de page -- et pourtant j'ai
cherché.
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.
On Wed, 21 Sep 2005 13:02:09 +0000, Nicolas George wrote:
l'indien wrote in message :
La communication entre 2 process peut être infiniment moins couteuse que la création de messages par le noyau.
Il n'y a aucune raison pour qu'elle le soit : comme le signale Luc, tout ce que ne fait pas le noyau doit être fait par le processus, et ce n'est pas plus rapide pour être en userland. En outre, pour de petits messages comme il est question ici, la copie du bloc du message doit être à peu près peanuts par rapport au coût d'un changement de contexte, sur un processeur du type x86 au moins.
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, ... Alors que si un process est blocqué, il est préempté. Ca joue aussi sur l'efficacité globale. 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. Il y a de toutes façon tellement de ressources gaspillée par l'architecture qu'on est vraiment plus à ça près, de nos jours.
Bon, ça commence à sentir fortement le troll roussi, par ici, non ?
entre 2 process, il y a effectivement 2 syscall mais le travail du noyau (si le code est bien fait) se résume à marquer la page contenant le message comme partagée entre les 2 process.
Tu penses à quel mécanisme d'IPC, là ? Je n'en connais aucun, dans Linux, qui fonctionne sur le principe du partage de page -- et pourtant j'ai cherché.
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.
lhabert
l'indien :
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.
Mumble lecture pas atomique mumble race-condition mumble sémaphore mumble passage par le noyau mumble.
l'indien :
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.
Mumble lecture pas atomique mumble race-condition mumble sémaphore mumble
passage par le noyau mumble.
Mumble lecture pas atomique mumble race-condition mumble sémaphore mumble passage par le noyau mumble.
Mumble futex mumble hyper-optimisé.
Nicolas George
l'indien wrote in message :
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.
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.
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é.
Bon, ça commence à sentir fortement le troll roussi, par ici, non ?
Oui, c'est bien, ça passe le temps.
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.
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.
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.
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é.
Bon, ça commence à sentir fortement le troll roussi, par ici, non ?
Oui, c'est bien, ça passe le temps.
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 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.
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.
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é.
Bon, ça commence à sentir fortement le troll roussi, par ici, non ?
Oui, c'est bien, ça passe le temps.
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.
