H2o: pourquoi avons-nous besoin de MAP_SHARED pour h2o_buffer_reserve()

y a-t-il d'autres processus qui y accéderont? sinon, pourquoi ne pas définir MAP_PRIVATE

L'intention d'utiliser mktemps + fallocate + mmap est de créer une mémoire tampon sauvegardée sur fichier afin que la quantité maximale d'espace pouvant être utilisée pour la mise en mémoire tampon des données soit limitée par l'_espace libre du disque au lieu du swap_. MAP_PRIVATE conflit avec cet objectif.

aussi, pouvons-nous utiliser mremap(2) au lieu de mmap(2) et munmap(2) sur une plate-forme prenant en charge mremap ?

Cela serait possible en supposant que les pages ajoutées ne seront pas anonymes. Notez également que si l'utilisation de mremap montre un changement notable dans les performances, cela signifierait que nous devrions voir comment minimiser les risques de déplacement des pages depuis le démappage (soit de manière permanente, soit dans le cadre du remappage) des pages mappées est l'opération la plus coûteuse. Et cela ne signifie pas nécessairement que nous devrions utiliser mremap .

Quoi qu'il en soit, la mise en mémoire tampon d'une grande quantité de données est une stratégie secondaire et je ne pense pas que ce soit une bonne idée de consacrer des efforts à l'amélioration des performances. Je préférerais travailler sur l'adoption de la demande de streaming (voir #1357) aux gestionnaires autres que le gestionnaire de proxy.

buffering large amount of data is a secondary strategy est le point.
suppose que le programme tombe rarement dans mktemps + fallocate + mmap .

demande de streaming gérée par un gestionnaire qui n'a pas besoin de grands tampons, n'est-ce pas ?

À mon avis, l'utilisation d'une ressource mmap partagée ou privée (même en tant qu'espace réservé de téléchargement temporaire) est une mauvaise idée. L'emplacement $TMP ou $TMPDIR peut être n'importe quoi dans l'environnement utilisateur, peut être un disque dur par exemple. C'est juste une étape supplémentaire à retenir pour un administrateur. Sans parler des téléchargements simultanés de fichiers volumineux créeraient facilement une pression sur la mémoire si $TMP est monté sur un disque RAM.

J'aime beaucoup votre suggestion et votre orientation pour faire fonctionner les demandes de streaming avec des gestionnaires non proxy. Dans l'attente et prêt à tester!