Enj0lras a écrit 250 commentaires

Rho le gros pâté de shell… Bah c’est pas très beau, mais bon faudrait une vraie comparaison (même démon et code équivalent).

Je suis un type allergique au shell, quand ça dépasse 500 lignes. Mais là, ce n'est pas le cas :

wc -l etc/rc                                                                                                  
74 etc/rc

J'ai pas tendance à appeler 74 lignes "un gros paquet". Suivant ton raisonnement, je dirais que systemd c'est "un gros paquet de C".
Si tu parles des scripts rc, écrits par les mainteneurs, ils ont une syntaxe claire, et offrent une plus grande souplesse de configuration que les unit systemd. Regardons si cette souplesse conduit à "un gros paquet" :

systemd :

[Unit]
Description=PostgreSQL database server
After=network.target

[Service]
Type=forking
TimeoutSec=120
User=postgres
Group=postgres

Environment=PGROOT=/var/lib/postgres

SyslogIdentifier=postgres
PIDFile=/var/lib/postgres/data/postmaster.pid

ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGROOT}/data
ExecStart= /usr/bin/pg_ctl -s -D ${PGROOT}/data start -w -t 120
ExecReload=/usr/bin/pg_ctl -s -D ${PGROOT}/data reload
ExecStop=  /usr/bin/pg_ctl -s -D ${PGROOT}/data stop -m fast

# Due to PostgreSQL's use of shared memory, OOM killer is often overzealous in
# killing Postgres, so adjust it downward
OOMScoreAdjust=-200

[Install]
WantedBy=multi-user.target

Taille :
26 lignes.
Documentation :
aucune.
Coniguration :
Possibilité de configurer le dossier contenant les fichiers de la base de donnée.

rcNG :

# PROVIDE: postgresql
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable PostgreSQL:
#
#  postgresql_enable="YES"
#  # optional
#  postgresql_data="/usr/local/pgsql/data"
#  postgresql_flags="-w -s -m fast"
#  postgresql_initdb_flags="--encoding=utf-8 --lc-collate=C"
#  postgresql_class="default"
#  postgresql_profiles=""
#
# See /usr/local/share/doc/postgresql/README-server for more info
#
# This scripts takes one of the following commands:
#
#   start stop restart reload status initdb
#
# For postmaster startup options, edit ${postgresql_data}/postgresql.conf

command=/usr/local/bin/pg_ctl

. /etc/rc.subr

load_rc_config postgresql

# set defaults
postgresql_enable=${postgresql_enable:-"NO"}
postgresql_flags=${postgresql_flags:-"-w -s -m fast"}
postgresql_user=${postgresql_user:-"pgsql"}
eval postgresql_data=${postgresql_data:-"~${postgresql_user}/data"}
postgresql_class=${postgresql_class:-"default"}
postgresql_initdb_flags=${postgresql_initdb_flags:-"--encoding=utf-8 --lc-collate=C"}

name=postgresql
rcvar=postgresql_enable
extra_commands="reload initdb"

start_cmd="postgresql_command start"
stop_cmd="postgresql_command stop"
restart_cmd="postgresql_command restart"
reload_cmd="postgresql_command reload"
status_cmd="postgresql_command status"

initdb_cmd="postgresql_initdb"

if [ -n "$2" ]; then
        profile="$2"
        if [ "x${postgresql_profiles}" != "x" ]; then
                eval postgresql_data="\${postgresql_${profile}_data:-}"
                if [ "x${postgresql_data}" = "x" ]; then
                        echo "You must define a data directory (postgresql_${profile}_data)"
                        exit 1
                fi
                eval postgresql_enable="\${postgresql_${profile}_enable:-${postgresql_enable}}
                eval postgresql_data="\${postgresql_${profile}_data:-${postgresql_data}}
                eval postgresql_flags="\${postgresql_${profile}_flags:-${postgresql_flags}}"
                eval postgresql_initdb_flags="\${postgresql_${profile}_initdb_flags:-${postgresql_initdb_flags}}"
        fi
else
        if [ "x${postgresql_profiles}" != "x" -a "x$1" != "x" ]; then
                for profile in ${postgresql_profiles}; do
                        eval _enable="\${postgresql_${profile}_enable}"
                        case "x${_enable:-${postgresql_enable}}" in
                        x|x[Nn][Oo]|x[Nn][Oo][Nn][Ee])
                                continue
                                ;;
                        x[Yy][Ee][Ss])
                                ;;
                        *)
                                if test -z "$_enable"; then
                                        _var=postgresql_enable
                                else
                                        _var=postgresql_"${profile}"_enable
                                fi
                                echo "Bad value" \
                                        "'${_enable:-${postgresql_enable}}'" \
                                        "for ${_var}. " \
                                      "Profile ${profile} skipped."
                                continue
                                ;;
                        esac
                        echo "===> postgresql profile: ${profile}"
                        /usr/local/etc/rc.d/postgresql $1 ${profile}
                        retcode="$?"
                        if [ "0${retcode}" -ne 0 ]; then
                                failed="${profile} (${retcode}) ${failed:-}"
                        else
                                success="${profile} ${success:-}"
                        fi
                done
                exit 0
        fi
fi

command_args="-D ${postgresql_data} ${postgresql_flags}"

postgresql_command()
{
    su -l ${postgresql_user} -c "exec ${command} ${command_args} ${rc_arg}"
}

postgresql_initdb()
{
    su -l -c ${postgresql_class} ${postgresql_user} -c "exec /usr/local/bin/initdb ${postgresql_initdb_flags} -D ${postgresql_data}"
}

run_rc_command "$1"

taille :
114 lignes.
Documentation :
les valeurs de configuration possibles sont documentées.
Configuration :
possibilité de choisir les options de la base de donnée, de créer une nouvelle base de donnée, et de choisir plusieurs profils.

Ramenons maintenant cela au même niveau de fonctionnalité que systemd :

# PROVIDE: postgresql
# REQUIRE: LOGIN
# KEYWORD: shutdown

command=/usr/local/bin/pg_ctl

. /etc/rc.subr

# set defaults
postgresql_enable=${postgresql_enable:-"NO"}
eval postgresql_data=${postgresql_data:-"~${postgresql_user}/data"}

name=postgresql
rcvar=postgresql_enable

start_cmd="postgresql_command start"
stop_cmd="postgresql_command stop"
restart_cmd="postgresql_command restart"
reload_cmd="postgresql_command reload"
status_cmd="postgresql_command status"

postgresql_command()
{
    su -l pgsql -c "exec ${command} -D ${postgresql_data}  -w -s -m fast ${rc_arg}"
}

run_rc_command "$1"

Lignes :
27

Ça ressemble vachement à systemd, j'ai l'impression. Des déclarations de variables pour les commandes à éxécuter, avec la possibilité de factoriser le code dans une fonction. J'ai l'impression que ton commentaire sur la syntaxe illisible est un troll, je te mets au défi de me donner un argument objectif sur ce point.

• pkgsrc est l'hisotrique gestionnaire de paquets des bsd

C'est peut être un peu exagéré de dire ça. Historiquement, sous BSD la gestion des paquets tiers se fait avec un arbre de ports. Chaque port est un Makefile, quelques métadonnées, et un des patchs éventuels. Pour installer un paquer, il suffit de faire make install dans le repertoire du port, ce qui va télécharger les sources et installer le logiciel à l'emplacement adéquat.

Quand les divers BSD se sont séparés, ils ont hérité de ce système, mais ce système a évolué différement dans chacun des OS, un peu comme les systèmes de paquet sous GNU/Linux. pkgsrc est l'abre des ports chez NetBSD, celui de freeBSD et celui d'openBSD sont tout les deux appelés "ports", mais ils sont aussi différents.

Un des attouts les plus revendiqués de pkgsrc est sa portabilité. Il fonctionne notament sur NetBSD, mais aussi GNU/Linux, Solaris, Minix, DragonFlyBSD, et sur diverses architectures. Il est donc loin d'être isolé. Toutefois, les ports FreeBSD commencent à évoluer dans cette direction durant ses évolutions récentes.

Historiquement encore, des scripts ont été développés pour installer des paquets binaires, les vénérables pkg_add, pkg_radd, pkg_info. Ils sont eux aussi un peu différents pour tout les OS. Toutefois, ce système est assez primitif vis à vis de la gestion des dépendances et des mises à jour, ainsi que dans sont interface. Pour pallier aux divers problèmes de ces outils, des projets sont nés.

pkgin est un gestionnaire de paquet binaires qui repose sur pkgsrc en effet, et qui utilise en fait les outils précédement cités si je ne dis pas de bétise, mais qui fournit une interface plus simple pour gérer des dépôts et des mises à jours.

pkgng lui est un projet pour les ports FreeBSD, c'est pour ça qu'il est indépendant de pkgsrc. Sont but premier est de fournir des paquets binaires issus des ports FreeBSD. Mais, contrairement à pkgin, il ne se base pas sur les anciens outils pkg_add, pkg_radd etc. Par contre, les paquets binaires, qui ont leur propre format, sont générés et compilés à partir de l'abre des ports.

Les approches sont différentes, peut être que pkgsrc aurait intérêt à passer à pkgng, mais mon impression est que pkgsrc est plus conservatif en ce moment que les ports freeBSD (une des raison qui ont motivées la personne qui a développée Dports, le portage semi automatique des ports FreeBSD vers DragonFly). Il est tout à fait possible d'adapter pkgng à pkgsrc, mais je ne connais pas la charge de travail nécéssaire pour le faire.

De toute manière, l'effort principal de maintenance n'est pas au niveau de pkgng ou pkgin, il est dans la maintenance des ports, leur mises à jour pour mieux gérere les dépendances entre les paquets binaires ou les options de compilation pour les paquets binaires. Et du aux différences entre pkgsrc et les ports, le code ne peut pas vraiment être partagé entre les deux.

Ça ressemble un peu à une discussion de trotskistes sur la nature de la propriété privée du choux par les paysans russes en 1921. Dans tout les cas, je suis d'accord, c'est pour ça que j'ai voté oui.

Il utilise la libc standard.

Ce n'est pas le cas. Go n'utilise pas la libc car l'ABI go n'est pas la même que l'ABI C standard (c'est l'ABI de plan9). Il faut cgo pour lier à des bibliothèques C, et comme go doit être compilable sans cgo car cgo n'est pas supporté par tout, la lib standard de go n'utilise pas cgo partout.

go a sa propre lib système, il y a du code assembleur pour effectuer les appels systèmes sur chaque plateforme sans passer par la libc. C'est d'ailleurs ce qui rend go un peu plus dur à porter que d'autres langages.

J'aime beaucoup go parce que sa syntaxe est claire et simple et que sa lib standard est cohérente et très fournie. Toutefois, je trouve que go a quelques problèmes fondamentaux cachés sous sa simplicité apparente.

Le polymorphisme en est un. Le système de type n'est tout simplement pas assez puissant. L'utilisation de l'héritage pour fournir un sypertype pour un ensemble de types à une fonction ou à une structure de donnée polymorphe atteint vite ses limites. Je ne comprends pas l'obsession des développeurs à éviter toute autre forme de polymorphisme (générics, ou autres).

Ces limites sont tellement présentes que les devs ont inclu des structures de données polymorphes dans le langage (maps, chans, et tableau) pour contourner les problèmes les plus courants. Toutefois, cela reste limité à ce que le langage supporte, et je trouve que go manque vite de flexibilité.

J'ai par exemple eu l'occasion d'écrire une DB en go, en utilisant des arrays comme zone mémoire dans laquelle gérer l'allocation de blocs (pour ne pas avoir à utiliser le GC et les objets natifs, ce qui s'avère lent pour une DB). J'avais donc besoin d'écrire deux structures de données qui sont des listes de tableaux (pour éviter le realloc), l'une étant un tableau de bytes, l'autre un tableau d'entiers. Cela est impossible sans écrire le code deux fois, ou sans utiliser de hack pour sérialiser les entiers en tableau de byte. En effet, il est impossible d'allouer une slice de manière polymorphe. Il faut spécifier statiquement le type de la slice, mais on ne peut pas faire ça sans préprocesseur, parce qu'il n'y a pas de génériques/templates/autre chose. De même, il n'y a pas de supertype qui inclue les slices/arrays/maps. Il faut passer une "factory" qui alloue des nouveaux blocs, et on se retrouver à recopier le même code pour int et byte.

j'ai beaucoup apprécié go au début, mais plus je l'ai utilisé et plus je l'ai trouvé bancal, et j'ai été très déçu par ce langage.

Je ne comprends pas pourquoi tu parles de risque. Il y a déjà une concurrence entre ZFS et btrfs. Et c'est tant mieux, parce que btrfs a profité du design de ZFS, et peut être qu'a l'avenir ZFS s'en inspirera. C'est du logiciel libre, la concurrence quand elle est bien faite c'est aussi de la coopération, ça donne plus de choix à l'utilisateur, ça donne de meilleurs produits/outils. J'aurais plus tendance à dire que c'est un bénéfice qu'un risque : on se fiche de savoir qui gagne tant que les deux sont utiles à des gens, que des développeurs sont contents de travailler dessus, et que la co-existence améliore les choses.

Equivalent en terme de fonctionnalité, équivalent pour l'utilisateur oui. Mais un FS est loin de se définir par ses fonctionnalités, il est avant tout caractérisé par son format sur le disque, ses structures de donnée en mémoire, et les algorithmes qu'il utilise. Et cela est bien plus important que les fonctionnalités qu'il fournit a un instant donné, car cela influence grandement les fonctionnalités futures qui peuvent être ajoutée, et la facilité avec laquelle cela peut être fait, ainsi que les performances.

Donc, je pense que ça aurait au moins intéressé des développeurs, et les utilisateurs précurseurs. Dans tout les cas, je trouve que ton argument est caduque, parce que btrfs n'attire pas grand monde aujourd'hui. Il crée le buzz, mais n'est pas tant que ça utilisé pour de vrai, ce qui fait que la situation aurait été identique, sauf que le FS aurait été utilisable.

Entre un FS similaire à ext4 en fonctionnalités et en stabilité, mais qui pourrait supporter tout ça dans 2ans sans que le format disque change (et dont le support serait petit à petit ajouté au fil des maj noyaux et que je pourrais commencer à utiliser sur mes FS existant), et un FS qui supporte tout ça aujourd'hui mais que je ne peux de toute manière pas utiliser parce qu'il est trop instable, mon choix est vite fait.

Je ne connais pas assez le développement de btrfs pour avoir un avis réaliste, mais mon impression d'utilisateur est que les devs de btrfs ont voulu tout coder d'un coup. Et leur priorité a toujours été d'ajouter des features (compression, deduplication, etc) au lieu de stabiliser le coeur du FS. Du coup, en tant qu'utilisateur, on a un FS instable qui plante souvent (je suis repassé à ext4 en 3.5, j'en avais marre). Le fait que fsck ait été développé si tard est assez révalateur.

Il aurait surement été plus payant de stabiliser le coeur du FS, après avoir design en tenant compte des features qui devaient être ajoutées, puis simplement après de commencer à ajouter des features ou des optimisations de performance, de manière incrémentale.

À noter que DragonFly inclu une implémentation d'udev. Cela dit, il manque des fonctions dans libdevattr (l'équivalent de libudev), et udev utilise sysfs sous linux pour nommer ou rechercher les devices. Il n'y a pas de sysfs dans dragonfly (sauf une vieille implémentation pour l'architecture i386).

La question est de savoir s'il est plus simple de compléter cette implémentation de udev, ou de tout convertir dans wayland/mesa pour utiliser les mécanismes bsd.

Tu as sûrement raison. J'ai réduit la taille, je vais voir si ça joue dans les semaines qui vienne. Merci.

ça ne change strictement rien… C'est des appelles systèmes. Et libcgroups est largement assez petite pour que des bindings puisses être écrits en moins d'une après midi. Surtout que c'est même inutile, car la majorité des opérations sur les cgroups peut se réaliser en utlisant l'API unix sur les fichiers. C'est un des points forts des crgoups.

Mon but n'était pas de lancer un troll sur les langages, juste de faire remarquer qu'écrire un logiciel en C apporte des contraintes d'architecture qu'à mon avis systemd ne respecte pas. Je ne suis pas d'accord avec le fait que l'architecture est entièrement dé-corrélée du langage. Si tu écris ton logiciel dans un langage qui a une notion de propriété de la mémoire forte, tu n'as pas forcément besoin de séparer les composants dans différents processus, parce que la séparation de privilèges a lieue déjà au niveau du langage d'une certaine manière.

Si tu prends l'exemple de rust, vu que les pointeurs définissent la propriété de la zone mémoire pointée, c'est directement au niveau du langage que la séparation des espaces mémoire est gérée, donc il n'y a pas forcément besoin de séparer les contextes d’exécution dans des espaces mémoire distincts. Quand au fait de s'interfacer avec le noyau, je trouve que c'est un faux argument. Il y a des bindings avec l'API unix dans quasiment tout les langages que je connaisse. Tu n'as vraiment pas besoin de C pour effectuer des syscalls.

Je vais essayer ça, mais la doc semble dire que c'est pas la peine d'utiliser ça si on utilise déjà une limitation de taille.

J'ai essayé d'écrire une dépêche pour chaque nouvelle version récemment pour faire exactement ça. Ça me fait plaisir que ça ai fonctionné dans une certaine mesure. Le problème c'est que c'est toujours plus marrant de coder que de passer du temps à raconter ce que l'on code !

C'est très possible. J'ai la configuration par défaut pour SystemMaxFileSize cependant. J'ai suspecté la compression aussi, mais en la désactivant, le problème persiste.

Merci de me rapeller pourquoi j'avais cessé de fréquenter linuxfr. Moi qui avais eu l'envie de recommencer à lire les commentaires, tu m'en fais passer l'envie à nouveau. J'économiserai du temps.

Je te remercie pour tes conseils. J'en ai déjà appliqués quelques uns, ce qui a rendu journalctl bien plus utilisable. Toutefois, les pics d'utilisation CPU que je remarque encore de manière épisodique (moins d'une fois par semaine en général) ont lieu dans journald lui même alors que je ne fais aucune requête utilisateur. C'est assez agacant d'entendre soudainement son ventilateur se mettre à souffler pendant une petite minute pendant que journald sature les accés disque et le cpu.

Pour préciser, les choses, j'ajoute un autre commentaire.

J'aimerais un jour que tu arrêtes de répondre en considérant qu'il y a une vérité, avec des gens qui ont raison et des gens qui ont tord, et que tout le monde est con quand il ne pense pas comme toi. Je ne suis pas anti-systemd mais je considère que j'ai quand même le droit d'avoir une opinion sur la manière de développer des logiciel (relis le titre). Et si tu ne penses pas que le fait qu'un logiciel soit écrit en C soit un problème, soit. Mais admets quand même que certains puissent le penser, et je te prie d'arrêter de prendre ce ton hautain quand tu réponds à mes commentaires (et ceux des autres si possible). Tu aurais pu me demander pourquoi je considérais ça comme un problème au lieu de répondre comme si je venais de proférer la pire merde de l'histoire du monde et de troller inutilement.

Le C est quand même un langage très très faible au niveau du typage et de la sureté qu'il apporte. Il est très simple d'ajouter des failles et des bugs dans un code en C. Si tu relis mon commentaire précédant, tu te rendras compte que je disais qu'a mon avis, un logiciel écrit en C ne devrait pas avoir ce genre de design monolithique. En effet, la surface d'attaque et de bugs est plus grande. De plus, en re-codant divers services, il y a plus de chance d'introduire de nouveaux bugs alors que réutiliser du code existant est potentiellement plus fiable et plus simple, car le code a été utilisé pendant des années et a plus de chance d'être stable. Donc, à mon avis quand on code en C, on a tout intérêt à coder de manière modulaire et de séparer les privilèges dans différents contextes de sécurités, en utilisant les mécanismes de l'OS sous-jacent. POur unix, ça revient à séparer le code en plusieurs processus qui ont différente permission, et à communiquer via l'IPC, essentiellement des pipes ou des sockets unix. Maintenant, si tu considères que ça n'est pas souhaitable, dis moi pourquoi au lieu de troller.

Ta capacité à être détestable me sidère chaque jour un peu plus. Mais pour répondre rationnenellement à ton troll, j'aimerais que tu relises et que tu remarques que ré-écrire un logiciel de plusieurs millions de ligne de code en C n'a rien à voir avec écrire un nouveau logiciel en repartant de zéro, en C.

Que tu n'aies pas le problème ne rend pas le problème moins réel pour autant.

Et je trouve assez incroyable que tu blames les daemons générant les logs quand un système de log scale mal. Syslog est parfaitement capable de traiter le volume de donnée.

Personnellement, je pense qu'il y a de très bonnes idées dans systemd, les plus importantes étant :

• suivi des processus (via les cgroups) permettant de faire de la supervision de daemons
• gestion fine des dépendances et parallélisme.
• gestion des évènements et démarrage de services conditionnels

Le problème c'est que je n'aime pas l'implémentation. Dire que systemd est découpé plein d'outils est très partiellement vrai. Un des plus gros problèmes c'est que systemd est écrit en C. Je trouve incroyable qu'on écrire un logiciel si gros en C de nos jours. Du coup, il me semble qu'un tel logiciel devrait vraiment être simplifié et découpé en plusieurs processus. Parce que systemd est gros. Presque un million de ligne de code en regardant tout ses composants.

Par exemple, le code pour parser les fichiers de conf tourne dans l'init, en mode privilégié, alors que ça pourrait très bien être un utilitaire séparé. De même, systemd sait monter des systèmes de fichier, alors que du code montant des systèmes de fichier existe déjà : il serait bon de le réutiliser, en faisant appel à un utilitaire séparé. Il en va de même pour le code de monitoring des processus, qui pourrait tourner dans un daemon distinct. L'overhead en communication n'est pas ce qui va ralentir l'éxécution de manière dommageable, je pense.

Pour résumer, je pense que le coeur d'init devrait n'ếtre capabable que de gérer des noms de service et garder la trace de ceux qui sont lancés, ainsi qu'une structure de donnée représentant les relations de dépendance (qui peut même être conservée sur le disque, sur le FS). Quand il veut lancer un service, il délègue au bon daemon (mountd, netd, …) et recevoir les événements de daemons de monitoring ( (u)devd, netd, mountd, monitord, pour regarder quels process meurent, etc).

La surface d'attaque est grandement diminuée, et si un des daemons plantes, tout les processus du système ne meurent pas. La tolérance au bug est beaucoup plus forte, ainsi que la ré-utilisation de code. Il est ainsi possible de démarer en mode dégradé dans n'importe quelle condition.

Chez moi, journald facilite surtout l'utilisation de mon CPU. Ceci n'est pas un troll, j'observe très souvent journald qui prend 80% d'un de mes deux coeurs, sur un netbook c'est assez génant.

À tel point que moi, je me sers de poudrière comme test de régression. Par exemple, j'ai du modifier le code de résolution des chemins de fichier. Après les tests basique, une exécution de poudrière : si ça survit plus de 15 minutes, ça veut dire que c'est déjà pas mal stable.

Je sais que récemment Matt Dillon s'en est servi pour tester un peu HAMMER2, le nouveau système de fichier. Il s'en est servi aussi pour éliminer le plus de contention de verrous possible dans le noyau, voir ce mail pour ces que poudrière a permis d'identifier :
- http://lists.dragonflybsd.org/pipermail/users/2013-October/090181.html
- http://lists.dragonflybsd.org/pipermail/users/2013-October/090181.html

Pour ce qui est du giant lock,(appelé MPLock dans BSD si je me souviens bien), je ne sais pas, par contre il y a bien un point où ils ne sont pas novateurs par rapport à DragonFlyBSD dans ce paragraphe, c'est les unmapped buffers. DragonFly a introduit xio (désolé, pas de page de manuel, oui c'est assez triste) il y a 9ans. Il s'agit d'une implémentation de buffers non mappés.

Je vais essayer de résumer la situation telle que je la comprends, une partie des informations est peut être erronée, mais il me semble que le problème n'est pas le Giant Lock.
Un noyau unix présente aux applications une abstraction du matériel, et permet aux applications de partager celui ci. Les buffers jouent une place importantes dans cette tâche, car ils permettent de gérer des données d'entrée/sortie. Ils sont notament présents dans la couche VFS (systèmes de fichier) ou dans la pile réseau. L'interface couramment utilisée sous BSD s'appelle uio, elle date des temps anciens d'unix qui échappent à mes maigres talents d’archéologue. Hormis les détails d'implementation parce que ça stoque plus d'infos qu'un simple buffer, il s'agit de buffers classiques, qu'on peut résumer à un espace de mémoire et la taille du buffer. Si on veut allouer un nouveau buffer simple, il faut allouer de la mémoire virtuelle sur le tas, soit dans celle du noyau, soit dans le tas processus utilisateur.

Pour allouer des buffers sur le tas, il faut créer un mapping mémoire et reserver un espace contigu dans la mémoire virtuelle. Cette opération modifie la table des pages. Les noyaux BSD, (comme linux) que l'espace mémoire du noyau ne soit pas un espace distinct : il s'agit juste d'une zone mémoire mappée dans la "hight memory", c'est à dire le haut de l'espace d'addressage virtuel de chaque processus. C'est à dire que tout les processus en cours d'execution partagent ce mapping. S'il on crée un buffer, on doit donc informer tout les cpu que le mapping de cette zone à changé. Cela implique une synchronisation par Inter process interupt du TLB pour invalider l'ancien mapping. Il s'agit donc d'un point de contention sur les systèmes SMP.

Les buffers non mappés répondent à ce problème. Au lieu de mapper de la mémoire physique dans l'espace d'addressage, le buffer est une liste de page mémoire physique telle que représentées par le système de gestion de la mémoire virtuelle. Quand on veut écrire ou lire le buffer, on peut modifier directement et une à une ces pages mémoire physique. Bien évidement, c'est moins intuitif qu'un simple memcpy d'un block contigu de mémoire, mais en fournissant une api intuitive, le gain est substantiel. En effet, pour créer un buffer, il suffit desormais de trouver assez de page mémoire physique disponibles, et de les verouiller pour informer le système de gestion de la mémoire qu'elles sont utilisées. Il y a bien sûr là encore des verrous à traiter, mais avec un système de verrou à grain fin dans la gestion de la mémoire, les collisions sont beaucoup plus rare, il n'y a plus de synchronisation de tout les cpu à chaque fois. Ce gain peut être très important, il semble que les premières utilisations de xio sous dragonfly étaient pour un système de passage de message pour applications en espace utilisateur, et les archives de l'époque affirme que le gain était de 20%.