Linux 7.4 active les large folios pour accélérer les systèmes de fichiers FUSE

29 septembre 2026. Michael Larabel de Phoronix rapporte que le patch activant les large folios pour FUSE a rejoint la branche for-next et devrait être fusionné dans Linux 7.4. Septembre 2026. La série fait suite aux améliorations FUSE déjà intégrées à Linux 7.3 pour les systèmes de fichiers en espace utilisateur. Fin 2026. Linux 7.4 est pressenti pour être la version LTS de l’année si 7.3 n’est pas retenue. Pourquoi c’est important : les systèmes de fichiers FUSE — sshfs, les montages rclone, AppImage, gocryptfs — paient depuis toujours une taxe de performance, et les large folios en retirent une part mesurable sur les gros transferts.

Ce qu’est une large folio

Une folio est l’unité de gestion mémoire du noyau Linux depuis la série 5.16 : elle regroupe une ou plusieurs pages physiques contiguës sous un seul en-tête, là où l’ancien modèle manipulait chaque struct page isolément. Une large folio est simplement une folio qui agrège plusieurs pages — typiquement 16 Ko, 32 Ko ou plus, selon la taille de page de base.

L’intérêt est mécanique. Gérer un transfert de 256 Ko sous forme de 16 pages de 4 Ko oblige le noyau à payer le coût de gestion — verrous, compteurs de référence, entrées de cache de pages — 64 fois. La même quantité en une seule folio de 256 Ko ne le paie qu’une fois. Sur les chemins chauds du noyau, la différence se traduit directement en cycles CPU économisés et en meilleure localité des données.

Le mécanisme est déjà en production sur les systèmes de fichiers natifs comme XFS, ext4 ou btrfs. L’activer pour FUSE revient à étendre un levier éprouvé à une classe de systèmes de fichiers qui en était privée.

La conversion de struct page vers les folios est l’un des chantiers les plus longs du sous-système mémoire. Entamé vers 2020 sous l’impulsion de Matthew Wilcox, il a transformé, page par page, la gestion du cache de pages, des entrées-sorties et des systèmes de fichiers. Chaque conversion retire une branche conditionnelle et un déréférencement sur le chemin chaud, et c’est cette accumulation de micro-gains qui finit par se lire dans un benchmark FIO. L’activer pour FUSE est une étape de plus dans ce chantier, pas une innovation isolée.

La taxe FUSE, et pourquoi les large folios l’allègent

FUSE, pour Filesystem in Userspace, déplace la logique d’un système de fichiers hors du noyau, dans un processus utilisateur. C’est ce qui rend possible sshfs, les montages cloud de rclone, le format portable AppImage ou le chiffrement transparent de gocryptfs : écrire un système de fichiers devient une affaire de bibliothèque, sans module noyau à compiler ni risque de panique.

Le prix à payer, c’est un aller-retour entre noyau et espace utilisateur pour chaque opération, avec copie des données à travers la frontière. Chaque requête FUSE traverse ce pont, et plus les requêtes sont petites et nombreuses, plus la surcharge est lourde. Les large folios attaquent exactement ce symptôme : en regroupant plusieurs pages contiguës, elles réduisent le nombre d’unités à faire transiter, donc le nombre de traversées et la pression sur la couche d’échange noyau-utilisateur.

Le patch de FUSE n’active pas les large folios dans tous les cas. La condition est explicite : les grandes folios sont utilisées lorsque le système n’est pas sous pression mémoire. Sous tension, FUSE retombe sur les pages simples, là où la granularité fine reste préférable pour recycler la mémoire au plus juste.

Le banc retenu, passthrough_hp, mérite une précision. Depuis l’arrivée du mode passthrough dans libfuse, certaines opérations de lecture sont servies par le noyau sans boucle aller-retour vers l’espace utilisateur lorsque le fichier est déjà ouvert — le processus utilisateur ne voit passer que les métadonnées. Le mode haute performance pousse cette logique plus loin. Les large folios complètent le dispositif : là où le passthrough réduit le nombre d’allers-retours, les large folios réduisent le nombre de pages à gérer pour chaque transfert restant.

Les mesures : gains sur lecture à froid, hors pression mémoire

Phoronix a validé le patch sur passthrough_hp, le mode passthrough haute performance de libfuse, avec un banc FIO en lecture tamponnée. Deux fonds de stockage ont été testés : un backing tmpfs, et un backing XFS posé sur du NVMe, en privilégiant les lectures à froid — celles où les données ne sont pas encore en cache et où la gestion des pages pèse le plus.

Le résultat publié décrit des gains « très nets » sur les deux configurations, en complément des autres optimisations FUSE accumulées ces derniers mois. C’est cohérent avec la mécanique : la lecture à froid est précisément le scénario où la surcharge par page domine, car chaque page doit être allouée, remplie puis indexée séparément avant d’atteindre le cache.

Le contexte élargi renforce le tableau. Linux 7.3 a déjà reçu sa salve d’améliorations FUSE, et une optimisation distincte préparée pour Linux 7.4 accélère l’ouverture de fichiers en lecture d’environ 39 %. La direction est claire : les mainteneurs s’attaquent méthodiquement aux points où la surcharge utilisateur-noyau de FUSE se paie le plus cher.

Ce que ça change concrètement

Pour l’utilisateur, rien à configurer : l’activation est transparente et pilotée par le noyau, avec repli automatique sous pression mémoire. Ceux qui montent des volumes distants via sshfs ou rclone, qui exécutent des applications AppImage ou qui lisent de gros médias sur un système gocryptfs verront d’abord l’effet sur les transferts séquentiels importants — les premiers octets d’un fichier volumineux, les sauvegardes, les lectures de base de données en espace utilisateur.

La prudence reste de mise sur deux points. D’abord, ces gains ne concernent que FUSE : les systèmes de fichiers natifs profitent déjà des large folios depuis longtemps, et un sshfs restera structurellement plus lent qu’un montage noyau — la frontière utilisateur demeure. Ensuite, le bénéfice dépend du scénario : les charges faites de petites lectures aléatoires, où la contiguïté n’existe pas, n’ont rien à agréger et ne verront presque rien changer.

L’enjeu dépasse le confort. Si Linux 7.4 devient la LTS de 2026, cette amélioration FUSE sera figée dans les noyaux d’entreprise et de distribution pendant plusieurs années. Le travail fait maintenant sur la gestion des grandes folios profitera donc à une très large base d’utilisateurs, bien au-delà du cercle des amateurs de systèmes de fichiers exotiques.

Verdict

Si vous faites transiter de gros fichiers sur un montage FUSE — sauvegardes rclone, gros médias sshfs, bases de données en espace utilisateur — prévoyez la migration vers Linux 7.4 dès sa sortie : le gain sur les lectures à froid est acquis sans aucun changement de configuration, et le repli sous pression mémoire écarte le principal risque de régression. Si votre charge est faite de petites lectures aléatoires, ne déplacez rien d’urgence : les large folios n’ont rien à agréger, et votre goulot restera la traversée noyau-utilisateur elle-même. Et si vous poussez des noyaux en production, testez le patch passthrough_hp de libfuse en lecture tamponnée sur vos volumes avant de généraliser, en observant la latence mémoire autant que le débit — c’est le seul scénario documenté, et c’est là qu’il faut valider.

Références

• Phoronix — Large Folios Able To Deliver Big Performance Gains For FUSE With Linux 7.4 (Michael Larabel, 29 septembre 2026)
• Phoronix — Simple Optimization For Linux 7.4 Can Open Files For Reading ~39% Faster (Michael Larabel, septembre 2026)
• Phoronix — FUSE Improvements Head Into Linux 7.3 (Michael Larabel, septembre 2026)
• LWN.net — Kernel prepatch 7.3-rc5 (27 septembre 2026)