Meta, nouvel investissement dans jemalloc et renforcement de la collaboration open source

• jemalloc, un allocateur mémoire haute performance, est un composant fondamental qui joue un rôle d’infrastructure clé dans la pile logicielle de Meta, aux côtés du noyau Linux et des compilateurs
• Ces dernières années, un éloignement progressif des principes d’ingénierie fondamentaux qui guidaient le développement de jemalloc a entraîné une accumulation de dette technique, ralentissant les avancées
• Après avoir pris en compte les retours de la communauté et échangé avec ses membres, dont le fondateur du projet Jason Evans, le dépôt open source d’origine a été réactivé (unarchived)
• À l’avenir, l’accent sera mis sur la résorption de la dette technique, l’amélioration de l’allocateur Huge-Page, l’efficacité mémoire et les optimisations AArch64
• Meta réaffirme sa gestion à long terme de jemalloc et fait évoluer son approche pour développer le projet en collaboration avec la communauté

---

Place et importance de jemalloc

• jemalloc est un allocateur mémoire haute performance, un composant qui a constamment offert un fort effet de levier dans la pile logicielle de Meta
• Il s’est continuellement adapté aux évolutions du matériel et des couches logicielles supérieures, contribuant à la stabilité et aux performances de l’infrastructure de Meta aux côtés du noyau Linux et des compilateurs

Écart par rapport aux principes et remise en question

• Les composants logiciels fondamentaux exigent le plus haut niveau de rigueur entre pragmatisme et principes
• En raison de l’effet de levier élevé qu’apporte jemalloc, la tentation existe de rechercher des gains à court terme, ce qui exige une forte autodiscipline à l’échelle de l’organisation pour y résister
• Ces dernières années, un éloignement progressif des principes d’ingénierie fondamentaux qui guidaient le développement de jemalloc s’est produit
• Certaines décisions ont offert des bénéfices immédiats, mais la dette technique qui en a résulté a freiné les progrès
• Les retours de la communauté ont été pris au sérieux, et des échanges ont eu lieu avec ses membres, dont le fondateur du projet, Jason Evans
• Meta a profondément réfléchi à l’impact de sa gestion sur la santé de long terme de jemalloc et a partagé son changement d’approche
• Les travaux ont commencé pour éliminer la dette technique et reconstruire une feuille de route de long terme pour jemalloc

Un nouveau chapitre : désarchivage du dépôt et plans à venir

• À la suite des échanges avec la communauté, le dépôt open source jemalloc d’origine a été réactivé (unarchived)
• Meta peut ainsi continuer à assurer le rôle de steward du projet, avec une orientation centrée sur la réduction de la charge de maintenance et la modernisation de la base de code
  • Résorption de la dette technique : maintenir un état efficace, fiable et simple d’utilisation pour tous les utilisateurs grâce au refactoring et aux améliorations
  • Allocateur Huge-Page (HPA) : mieux exploiter les Transparent Hugepages (THP) afin d’améliorer l’efficacité CPU
  • Efficacité mémoire : optimiser l’efficacité mémoire en améliorant les mécanismes de packing, de caching et de purging
  • Optimisations AArch64 : garantir de bonnes performances par défaut sur les plateformes ARM64

Renforcement de la collaboration avec la communauté

• Meta met en avant la construction de la confiance par les actes et vise un développement sain de jemalloc
• Les retours et la participation de la communauté sont les bienvenus, avec l’espoir de construire ensemble l’avenir de jemalloc
• L’entreprise entend promouvoir une collaboration et un développement durables au sein de l’écosystème open source

[GN⁺]

Commentaires sur Hacker News

• À l’époque où je travaillais chez Facebook, je maintenais un patch du noyau pour améliorer le mécanisme de purge de jemalloc
  Il n’était pas très apprécié dans les communautés du noyau ou de la sécurité, mais il était efficace dans les benchmarks
  Le problème venait du fait qu’un zeroing se produisait lors de la réaffectation de la mémoire à un autre thread, ce qui affectait la localité du cache et les performances
  C’était inutile lorsqu’on réutilisait la mémoire au sein du même domaine de sécurité, mais il était difficile d’obtenir un consensus sur la définition exacte d’un « domaine de sécurité »
  La discussion associée se trouve sur la Linux Kernel Mailing List

  • C’est étonnant qu’on mentionne encore ce patch
    Nous avons réalisé des benchmarks très larges sur HHVM avant et après l’application de ce patch, mais au niveau système il n’y avait pas de différence statistiquement significative
    Il y a peut-être eu des améliorations sur certains microbenchmarks, mais comme cela n’avait pas d’effet sur les performances globales du système, le patch a été écarté du noyau
  • Je me demande quelle métrique s’est améliorée
  • Considérer que ce n’est pas grave si le contenu mémoire fuit entre processus à l’intérieur d’un cgroup me paraît être une hypothèse risquée

• Récemment, j’ai utilisé le mimalloc de Microsoft avec LD_PRELOAD pour exploiter des huge pages de 1 Go
  J’ai obtenu environ 20 % de gain de performance sur un programme intensif en mémoire
  C’est une sensation étrange d’améliorer les performances sous Linux avec une bibliothèque open source de MS
  J’ai l’impression qu’il faudrait plus de concurrence dans le domaine des malloc

  • J’ai testé plusieurs allocators, et le tcmalloc récent a donné les meilleurs résultats à la fois en temps et en mémoire
    Il s’agissait d’applications écrites en Rust, majoritairement liées statiquement
    Par exemple, sur app1, tcmalloc a réduit la RSS de 35 % et le temps de traitement de 30 % par rapport à glibc
    Tous les résultats ont été testés à partir du dépôt tcmalloc
  • Autrefois, il y avait beaucoup de publicités pour des allocateurs mémoire personnalisés dans des magazines comme Dr. Dobbs ou BYTE
    Même Turbo Pascal fournissait une API permettant de définir son propre allocateur mémoire
    Au final, l’approche « one size fits all » montrait déjà ses limites depuis longtemps
  • L’un des avantages des langages à GC est que le coût d’allocation/libération est regroupé, ce qui le rend plus visible lors du profiling
  • Le concept de memory pool de l’Apache Portable Runtime m’avait marqué
    On créait un pool par requête, puis on libérait tout d’un coup à la fin de la requête
    Je pense que malloc a encore beaucoup de marge pour évoluer dans ce sens
  • Selon les cas, mapper directement des huge pages via mmap peut être plus efficace que malloc
    Si le schéma d’allocation est simple, on peut obtenir de meilleurs résultats qu’avec un malloc tiers
    On considère malloc comme une boîte noire magique, mais en réalité ce n’est pas si extraordinaire

• Notre équipe a migré de glibc malloc vers jemalloc il y a deux ans
  L’usage mémoire a baissé de 15 à 20 % sur des services Python
  En revanche, dans un environnement conteneurisé, le réglage de oversize_threshold était important — mal configuré, cela provoquait des OOM
  Je me demande s’il existe des benchmarks comparant jemalloc et mimalloc sur des services de longue durée

• Comme références associées, je recommande Jemalloc Postmortem et
  Jemalloc Repositories Are Archived

• Je me demande si ce changement est lié à une pénurie mondiale de mémoire
  On pourrait très bien voir des calculs du type « remplacer l’allocateur mémoire permet d’économiser plusieurs millions de dollars par an »

  • Facebook cherchait déjà ce type de réduction des coûts par micro-optimisation il y a 10 ans
    Rien qu’avec 0,1 % de gain d’efficacité, il était possible d’économiser 100 000 dollars par mois
    Les principales économies venaient des coûts de refroidissement (HVAC) et de la réduction des achats de serveurs
    Aujourd’hui, les économies de mémoire sont aussi un gros sujet, mais ce n’était pas le cas à l’époque
  • Il ne s’agit pas seulement de coûts, l’amélioration de l’efficacité est aussi importante pour compenser les retards d’approvisionnement en mémoire
  • Chez Meta, il est courant de rechercher des économies de plusieurs millions de dollars
    Dès qu’un changement touche des milliers de serveurs, même une petite amélioration devient un gros chiffre
    Cette culture de l’amélioration quantifiée est bien installée
  • Vu la réputation de cette entreprise, il y a peut-être des raisons plus complexes qu’une simple pénurie de mémoire
  • Nous sommes à un moment où les LLM, l’électricité et l’efficacité mémoire des serveurs deviennent de plus en plus importants
    Même 10 % de gain de vitesse peut donner un avantage dans la compétition autour des LLM
    Les incitations à améliorer les performances sont très fortes

• En Australie, j’ai été licencié alors que je faisais de la programmation bas niveau
  J’adore vraiment résoudre ce genre de problèmes, mais le marché local est surtout centré sur du React CRUD, ce qui est frustrant

  • On recrute en AU sur des postes liés au traitement de données bas niveau. Lien dans la bio
  • Moi aussi, en Australie, je ne faisais que du React CRUD et je pensais la même chose
  • Si vous cherchez du télétravail, la page emplois d’Igalia pourrait vous intéresser
  • Les sociétés de HFT (IMC trading) font aussi beaucoup de ce type de travail d’optimisation bas niveau et recrutent actuellement en Australie
  • SIG recrute aussi pour des postes liés à cela à Sydney : SIG Careers

• Dans un projet de startup financé par la Banque mondiale, nous avons déployé Ruby + jemalloc en production
  Les améliorations en vitesse et en efficacité mémoire étaient nettes, ce qui a fortement réduit les coûts AWS
  C’était il y a 8 ans, et je me demande pourquoi jemalloc ne s’est toujours pas imposé comme standard

  • Dans la plupart des cas, c’est simplement un manque d’information ou de dynamique de changement
    Changer un système déjà en production n’est pas facile, même quand le bénéfice est clair

• Il existe aussi un cas d’usage de jemalloc pour remonter à la cause d’une fuite mémoire
  Voir le billet du blog technique de GOV.UK

• Meta a fusionné en masse le travail réalisé sur son fork interne
  C’est visible dans la PR #2863

• Je me demande s’il existe une ressource qui récapitule la chronologie ou l’histoire de jemalloc
  C’est un projet open source, alors pourquoi Meta en détient-il le contrôle de fait ?

  • Le créateur Jason Evans a récapitulé tout l’historique l’an dernier
    Voir le blog Jemalloc Postmortem
  • Si l’on regarde les commits des cinq dernières années, 4 des 6 principaux contributeurs sont des employés de Meta
    Les 2 autres pourraient aussi appartenir à Meta sans l’indiquer publiquement