Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le système de mise en cache du noyau Linux serait-il plus lent que les transferts E/S directs ? Non
Soutient Linus Torvalds

Le , par Bill Fassinou

53PARTAGES

10  0 
En informatique, un cache est une une mémoire qui enregistre temporairement des copies de données afin de diminuer le temps d'un accès ultérieur. La mise en cache permet de réutiliser efficacement des données précédemment récupérées ou traitées. Sous Linux, on utilise principalement le système de mise en cache appelé « page cache » ou cache de pages en français, mais il est également possible d’utiliser les transferts E/S directs.

Dans la pratique, les données mises en cache sont généralement stockées sur du matériel à accès rapide, comme la mémoire vive, et peuvent également être utilisées en corrélation avec un composant logiciel. L'objectif principal d'un cache est d'augmenter les performances de récupération des données en réduisant le besoin d'accès à la couche de stockage sous-jacente plus lente. En laissant la capacité au profit de la vitesse, un cache stocke généralement un sous-ensemble de données transitoires, contrairement aux bases de données où celles-ci sont généralement complètes et durables.

Dans la plupart des cas, le noyau Linux fait référence au « page cache » lors de la lecture ou de l'écriture sur le disque. De nouvelles pages sont ajoutées pour répondre aux demandes de lecture des processus en mode utilisateur. Si la page ne se trouve pas déjà dans le cache, une nouvelle entrée est ajoutée au cache et remplie avec les données lues sur le disque. Si la mémoire disponible est suffisante, la page est conservée dans le cache pendant une durée indéterminée et peut ensuite être réutilisée par d'autres processus sans accéder au disque.


Les concepteurs du noyau Linux ont implémenté le « page cache » pour répondre à deux exigences principales. Premièrement, cela va permettre au système de localiser rapidement une page spécifique contenant des données relatives à un propriétaire donné. Pour tirer le meilleur parti du cache de Linux, la recherche doit être une opération très rapide. Ensuite, le noyau doit être en mesure de sélectionner l'opération appropriée en fonction du propriétaire de la page. L'unité d'information conservée dans le cache de pages est, bien sûr, une page entière de données. Une page ne contient pas nécessairement des blocs de disque physiquement adjacents, elle ne peut donc pas être identifiée par un numéro de périphérique et un numéro de bloc.

Au lieu de cela, une page du cache de pages est identifiée par un propriétaire et par un index dans les données du propriétaire, généralement un inode et un décalage dans le fichier correspondant. Cependant, dans certains cas, comme celui des bases de données, où le volume de données à mettre en cache est trop important, les développeurs préfèrent utiliser une solution de contournement. Plusieurs applications de base de données utilisent les transferts E/S directs pour pouvoir utiliser leur propre algorithme de mise en cache de disque. La plupart d’entre eux implémentent leurs propres mécanismes de mise en cache qui exploitent la nature particulière des requêtes adressées à la base de données.

En effet, les développeurs estiment que pour ces types de programmes, le cache de pages du noyau n’aide pas. Au contraire, il est préjudiciable pour de nombreuses raisons. D’abord, expliquent-ils, beaucoup de caches de pages sont gaspillés pour dupliquer des données de disque déjà dans la RAM (dans le cache de disque de niveau utilisateur). Deuxièmement, les appels read() et write() seraient ralentis par les instructions redondantes qui gèrent le cache de page et la lecture anticipée. Idem pour les opérations de pagination liées aux mappages de mémoire de fichiers. Ces derniers citent également une troisième raison liée au fait que le cache de pages serait préjudiciable pour les serveurs de bases de données.

D'après eux, plutôt que de transférer les données directement entre le disque et la mémoire utilisateur, les appels read() et write() effectuent deux transferts : entre le disque et une mémoire tampon du noyau et entre la mémoire tampon du noyau et la mémoire utilisateur. Pour ces raisons, Linux offre un moyen simple de contourner le cache pages : les transferts E/S directs. Dans un transfert direct d'E/S, le noyau programme le contrôleur de disque pour transférer les données directement vers les pages appartenant à l'espace d'adressage en mode utilisateur d'une application à mise en cache automatique.

Le sujet a toujours été débattu dans la communauté Linux et vient de faire l’objet d’un litige entre Linus Torvalds et un contributeur du noyau Linux. En effet, dans un message publié sur la liste de diffusion du noyau Linux, Dave Chinner, un programmeur australien qui gère le système de fichiers XFS créé par Silicon Graphics (SGI) et pris en charge par de nombreuses distributions Linux, a indiqué que le cache de page est toujours beaucoup plus lent que les transferts E/S directs. « Pour une application hautement concurrente qui traite des données en vrac sur des fichiers volumineux stockés sur un stockage à haut débit, le cache de pages est toujours beaucoup plus lent que les transferts E/S directs », a-t-il écrit dans son message.


Dave Chinner

Sa déclaration rejoint celle citée un peu plus haut, selon laquelle, dans certains cas, comme celui des bases de données, où le volume de données à mettre en cache est trop important, il serait préférable d’utiliser une solution de contournement : les transferts E/S directs. Cela dit, Linus Torvalds, l’architecte principal du noyau Linux n’a pas apprécié le commentaire de son collaborateur sur la question de la mise en cache de données sur son système d’exploitation. Ce dernier a qualifié les propos de Dave Chinner de « pures conneries » avant de s’attaquer à lui dans un long message. « Vous avez déjà fait cette demande, et c'était déjà une connerie complète, et je vous ai appelé à ce sujet aussi », lui a-t-il lancé.

Il lui a fait remarquer que le mot clé dans "cache de pages" est « cache » et que cela marche très bien. « Les caches fonctionnent, Dave. Quiconque pense que les caches ne fonctionnent pas est un incompétent. Environ 99 % de tous les accès au système de fichiers sont mis en cache, et ils ne font jamais aucun transfert E/S direct. Le cache de page les gère parfaitement. Lorsque vous dites que le cache de page est plus lent que le transfert E/S direct, c'est parce que vous ne voyez même pas ou ne vous souciez pas de la rapidité des opérations. Cela se comprend puisque vous n'intervenez qu'une fois que des opérations d'information sont réellement effectuées », déclare Linus Torvalds sur la liste de diffusion.

Pour lui, toute personne opposée à cette idée n’y connaît absolument rien et Dave Chinner en fait partie. « Vous faites cette déclaration sans prendre en compte tous les cas que vous ne voyez pas et qui ne vous intéressent pas, car le cache de pages les a déjà traités pour vous. Il est bien mieux que les transferts E/S directs. À quelle fréquence utilisez-vous des magasins non temporels lorsque vous effectuez une programmation non IO ? À peu près jamais, peut-être ? Parce que les caches fonctionnent. Alors arrêtez-vous déjà avec votre argument stupide et malhonnête, où vous ignorez les effets de la mise en cache », a poursuivi Torvalds.

Quelque part dans son message, Dave Chinner a expliqué que les limites du cache de pages deviennent de plus en plus perceptibles au fur et à mesure que les disques SSD deviennent plus performants. Une chose avec laquelle Torvalds n’est toujours pas d’accord. « Et non, les disques SSD n'ont pas rendu les caches inutiles », a-t-il déclaré. Cependant, en réponse au long texte de Torvalds, Chinner a expliqué qu’il reste persuadé que le problème qu’il souligne est bel et bien réel. Pour Chinner, il est bien vrai qu’il existe beaucoup de cas où le cache de pages fonctionne normalement, car il est toujours plus rapide que la plupart des systèmes de stockage.

« En effet, vous n'avez même pas pris la peine de me demander de clarifier ce à quoi je faisais référence dans la déclaration que vous avez citée. Linus, personne ne peut parler d’E/S direct sans que vous criiez et jetiez tous vos jouets hors du berceau. Si vous ne pouvez pas être civilisé ou si vous ne pouvez pas écrire une explication condescendante de “mise en cache 101” à quelqu'un qui a passé plus de 15 ans à travailler avec des systèmes de fichiers et de caches, vous feriez bien mieux de ne rien dire », a lancé Chinner en réponse à Torvalds. Pour finir son message, Chinner a pris le soin de redonner à Linus Torvalds un nouvel exemple sur le cas qu’il aborde et qui selon lui met en évidence les limites du cache de pages.

« Le monde dans lequel je travaille compte une proportion importante d'applications dans lesquelles le jeu de données est trop volumineux pour être mis en cache efficacement ou est mieux mis en cache par l'application que le noyau. La mise en cache efficace des données par le cache de pages constitue l'exception plutôt que la règle. Par conséquent, les programmeurs utilisent les transferts E/S directs, car il est plus rapide que le cache de pages. C’est courant dans des applications telles que les grandes bases de données d’entreprise, les applications HPC, les applications d’exploration ou d’analyse de données, etc. Il y a énormément de monde qui utilise ces applications », a-t-il conclu dans son message.

Sources : Dave Chinner, Linus Torvalds

Et vous ?

Que pensez-vous des arguments avancés par Linus Torvalds et Dave Chinner ?
Le système de cache du noyau Linux vous semble-t-il optimal pour la mise en cache de volumes de données importants ? Pourquoi ?
Comment gérez-vous la mise en cache de volumes de données importants dans vos applications ?

Voir aussi

Linus Torvalds : « Je ne serai jamais doux, mais je serai plus poli » ! Le père de Linux indique qu'il va le simuler jusqu'à ce que cela arrive

Pour Linus Torvalds, ARM ne gagnera pas la concurrence sur le marché des serveurs à cause du niveau de fragmentation élevé et d'autres raisons

La version 5.1 du noyau Linux est disponible, optimise les E/S asynchrones et apporte d'autres nouvelles fonctionnalités

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 02/07/2019 à 10:19
Citation Envoyé par Ryu2000 Voir le message
N'y a t-il pas moyen de réaliser des tests ?
Il n'y a pas moyen de dire "Tenez ce sont des grosses bases de données et on va faire de la lecture et de l'écriture sans jamais passer par le cache" ?
Le problème est de se mettre d'accord sur un benchmark.

Tout système générique sera par moment non-optimal, mais en moyenne fonctionnera très bien.
Il peut être difficile de savoir quels sont ces moments non-optimal, les détecter, puis passer sur une gestion "fallback", sans surcoût supplémentaire.

On pourrait être tenté de faire sa propre cuisine au niveau applicatif, mais cela n'est pas nécessairement simple, et pourra même être moins optimum que la solution existante, ou pour des gains qui ne valent pas le temps investi dessus.

Sans compter, qu'il faut prendre en compte plusieurs hardwares, mais aussi l'utilisation globale de la machine. Cela ne sert à rien de gagner un pouillième sur une utilisation spécifique, mais de perdre à côté des perfs pour des raisons X ou Y.
Le système existant est déjà bien éprouvé, ce n'est pas n'importe qui peut faire mieux.
5  0 
Avatar de walfrat
Membre actif https://www.developpez.com
Le 02/07/2019 à 11:42
Dans tout les cas, il faut bien montrer qu'il y a un problème, ou plutôt une limitation dans le cas présent je dirais avant de vouloir faire mieux.

En outre il faut montrer aussi que le scénario produisant cette limitation exploite déjà au mieux le système.

Evidemment dans des cas aussi point, c'est plus facile à dire qu'à faire.

Par conséquent, les programmeurs utilisent les transferts E/S directs, car il est plus rapide que le cache de pages. C’est courant dans des applications telles que les grandes bases de données d’entreprise, les applications HPC, les applications d’exploration ou d’analyse de données, etc.
Il faut peut être aussi demander à ceux qui ont fait ces systèmes ce qu'il en est ? Ils court-circuitent vraiment le cache système ?
Si oui, estiment'ils que leur cas spécifique devrait être mieux gérer par l'OS ?
4  0 
Avatar de abriotde
Membre expérimenté https://www.developpez.com
Le 02/07/2019 à 14:07
les disques SSD n'ont pas rendu les caches inutiles
Tout a fait vrai le rapport est toujours gigantesque entre la vitesse d'un SSD (qui a d'ailleurs lui aussi sont cache) et un cache. Ne serait-ce que le temps du bus de transfert... par contre s'il existe un seuil a partir duquel le cache perd de l'intérêt, ce seuil sera plus bas avec des SSD.
Je pense que ce seuil doit exister. Mais de ce que je comprends, Linux contient un contournement du cache pour les application le désirant. C'est donc qu'il peut avoir un intérêt. Ce que réfute Linus, c'est qu'il faille permettre de le généraliser à tout le noyau, chose que je comprends très bien. Le cache a toujours un intérêt pour tout ce qui tourne autour des E/S.
D'ailleurs la réponse de Dave Chinner n'est pas aussi vindicative, c'est un peu "Ok je comprends, mais peut-être que dans le futur", histoire de ne pas perdre la face.
3  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 02/07/2019 à 17:18
Citation Envoyé par Ryu2000 Voir le message
Un disque dur doit faire au minimum 1 To (à moins que ce pour l'OS auquel cas ça peut être plus petit).
Presque personne n'a besoin d'avoir un disque dur de 1To pour faire tourner un ordinateur...
A part les gamers, et les professionnels qui utilisent beaucoup de données.

Il n'y a qu'à regarder la profusion de tablettes qui remplacent l'utilisation des PCs dans pas mal de famille.
Ces tablettes n'ont pas plus que 64Go pour la plupart.
3  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 03/07/2019 à 20:08
Pitoyable. Linus n'est plus ce qu'il était.
Si justement, il est égal à lui-même. Il a toujours été comme ça que je sache.
3  0 
Avatar de Ryu2000
Membre extrêmement actif https://www.developpez.com
Le 02/07/2019 à 10:06
Citation Envoyé par Bill Fassinou Voir le message
Que pensez-vous des arguments avancés par Linus Torvalds et Dave Chinner ?
N'y a t-il pas moyen de réaliser des tests ?
Il n'y a pas moyen de dire "Tenez ce sont des grosses bases de données et on va faire de la lecture et de l'écriture sans jamais passer par le cache" ?

Citation Envoyé par Bill Fassinou Voir le message
Il lui a fait remarquer que le mot clé dans "cache de pages" est « cache » et que cela marche très bien. « Les caches fonctionnent, Dave. Quiconque pense que les caches ne fonctionnent pas est un incompétent. Environ 99 % de tous les accès au système de fichiers sont mis en cache, et ils ne font jamais aucun transfert E/S direct. Le cache de page les gère parfaitement. Lorsque vous dites que le cache de page est plus lent que le transfert E/S direct, c'est parce que vous ne voyez même pas ou ne vous souciez pas de la rapidité des opérations. Cela se comprend puisque vous n'intervenez qu'une fois que des opérations d'information sont réellement effectuées », déclare Linus Torvalds sur la liste de diffusion.

Pour lui, toute personne opposée à cette idée n’y connaît absolument rien et Dave Chinner en fait partie. « Vous faites cette déclaration sans prendre en compte tous les cas que vous ne voyez pas et qui ne vous intéressent pas, car le cache de pages les a déjà traités pour vous. Il est bien mieux que les transferts E/S directs. À quelle fréquence utilisez-vous des magasins non temporels lorsque vous effectuez une programmation non IO ? À peu près jamais, peut-être ? Parce que les caches fonctionnent. Alors arrêtez-vous déjà avec votre argument stupide et malhonnête, où vous ignorez les effets de la mise en cache », a poursuivi Torvalds.
2  0 
Avatar de BugFactory
Membre expérimenté https://www.developpez.com
Le 02/07/2019 à 15:05
Citation Envoyé par Neckara Voir le message
D'ailleurs quand le transfert des SSD équivaudra à celle de la ram (si cela arrive un jour), est-ce qu'on ne finira pas par fusionner la RAM et le SSD ?
Par exemple en utilisant qu'un partition SWAP, voire en prenant au maximum toute la place non-utilisée du disque ?
Ça changerait radicalement la façon dont on fait de l'informatique. Tout est en même temps dans la RAM et dans le disque dur puisque ce serait le même composant. Plus besoin d'enregistrer quoi que ce soi. Plus de temps de chargement : tout est déjà en mémoire. Plus d'attente quand on éteint ou qu'on rallume la machine. Etc, etc, etc. Le concept de partition SWAP serait tout simplement obsolète.

Dommage que ça n'ait pas l'air de devoir arriver, les demandes sur la RAM et sur le disque dur sont trop différentes.
2  0 
Avatar de Steinvikel
Membre expérimenté https://www.developpez.com
Le 03/07/2019 à 0:04
Citation Envoyé par Neckara  Voir le message
Les deux principales différences entre la RAM et le SSD sont :
  • la volatilité ;
  • la capacité.

En fait, comme le dit Ryu2000, la principale différence viens du fait que la RAM est plus rapide (et réactive). A cela s'additionne en second plan ta liste comme des limitations techniques. Il y a pourtant un net avantage à la RAM sur le SSD/HDD auquel personne ne semble penser au premier abord : elle permet un nombre de réécritures vertigineux !

Citation Envoyé par Ryu2000  Voir le message
Ça n'arrivera jamais, il y aura toujours une RAM plus rapide. (ils vont pas se se dire "à DDR6 on arrête tout")
L'autre jour je cherchais la vitesse de l'SDR, ou de la DDR1 pour la comparer avec la vitesse des meilleurs SSD actuel, mais j'ai pas réussi à comparer comme je voulais...

ça arrivera "probablement"... comme la majeure partie des évolutions technologiques. D'ailleurs il y a depuis qq années, une anonce par an qui va dans ce sens, la dernière en date :
[quote]Des chercheurs de l’Université de Lancaster auraient élaboré une mémoire électronique universelle. Celle-ci permettrait de remplacer à la fois la DRAM et la mémoire flash. Manus Hayne, professeur de physique, explique : « la mémoire universelle, qui possède des données stockées de manière sécurisée et facilement modifiables, est largement considérée comme irréalisable, voire impossible. Mais notre appareil démontre ces propriétés contradictoires ». ...pour un coût énergétique inférieur d'un facteur 100, tous les brevets assortis sont en cours de dépôt.[\quote]

La mémoire DDR1-SDRAM ayant un bus mémoire cadencé à 100 MHz est équivalente en débit de donnés à de la SDRAM à 200 MHz. Mais l'accès se fait non plus par 1 words par cycle, mais par 2 words par demi-cycle... puis par 4 en DDR2, puis 8 pour la DDR3-4-5. Une DDR4-3200 (CL16) permet un débit de 25 Go/s ...à comparer aux 1 Go/s de la SDR-133 et aux quelques Go/s des SSD les plus haut de gamme de 2019.
Reste à comparer la réactivité, de l'ordre de 5 à 45 ns pour la RAM, à ??? pour les SSD les plus réactif.

Attention aux comparatif de SSD... certains sont juste du M.2 en RAID et sont présenté comme un SSD classique dans les bench.
2  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 02/07/2019 à 16:15
Citation Envoyé par Ryu2000 Voir le message
Ça n'arrivera jamais, il y aura toujours une RAM plus rapide. (ils vont pas se se dire "à DDR6 on arrête tout"
...

Tu sais, il y a quand même des contraintes, qu'elles soient physiques, ou financières.
Ce n'est pas parce qu'ils se lèvent un matin en se disant, tiens on va faire le DDR1337 cette année, que tout à coup les performances doublent.

Les deux principales différences entre la RAM et le SSD sont :
  • la volatilité ;
  • la capacité.


En RAM, on atteint déjà de 32 à 64Go sur des ordinateurs fixes. Cela commence déjà à être une capacité suffisante pour un disque.
Il "suffirait juste" de rendre cela non-volatile pour un surcoût moindre et on aura des SSD/RAM. Possiblement en fusionnant les deux technologies à même le disque (un peu comme les mix SSD/HDD) où la partie SSD sert de cache au HDD.

Fin bref, cela n'a rien d'impossible.
Sachant aussi que la physique fait que la RAM n'aura de toute manière pas des performances infinies.

Citation Envoyé par Ryu2000 Voir le message
En parlant de SSD, on en revient au problème de la spécialisation, il y a eu une panne d’électricité dans un site de production partagé par Western Digital et Toshiba, du coup ils vont peut-être devoir augmenter les prix des SSD.
Ça rappelle l’inondation dans la région où toutes les usines de disque dur se trouvaient (Taiwan ?) qui avait fait monter le prix de tous les disques dur à l'époque...
Quel est le rapport ?
1  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 02/07/2019 à 18:02
Citation Envoyé par Ryu2000 Voir le message
Un disque dur doit faire au minimum 1 To (à moins que ce pour l'OS auquel cas ça peut être plus petit).
Je ne dépasse même pas les 100Go d'espace disque utilisé (du -h /)…

À moins de stocker des films en 4K, d'installer des jeux AAA, ou de faire de l'infographie/montage, il n'y a absolument pas besoin de 1To.
À la limite 128Go est largement suffisant pour Mme Michu.

Citation Envoyé par Ryu2000 Voir le message
Bon après il y a longtemps qu'on peut utiliser de la RAM comme disque dur (tu mets ton OS en RAM et ça va aller encore beaucoup plus vite qu'un SSD).


Faut pas arrêter ton ordinateur par contre, et gare au coupures de courants.

Citation Envoyé par Ryu2000 Voir le message
AMD avait racheté RAMDisk
C'est le principe de tmpfs sous Linux en somme.

Citation Envoyé par Ryu2000 Voir le message
Maintenant qu'il y a la fibre optique, les gens peuvent télécharger des vidéos qui font 32 Go chacune.
Ouais, Mme Michu va télécharger un film en 8K pour la regarder sur son écran 1080p.
1  0