Discussion :

[khazna]

Bonsoir à tous,

Je souhaiterais mieux comprendre comment ça se passe lorsque l'on utilise des DMAs au niveau des caches du CPU. (Pas par plaisir, juste parce que je suis obligé pour mon boulot).
Je sais que l'utilisation de DMAs pour faire des opérations mémoires sans le CPU est très fréquent. Cela pose des problèmes pour la cohérence des caches sur le processeur central par contre, donc il faut au moins pouvoir invalider des lignes de cache lors de la réception de la notification de fin d'opération, ou alors il faut que ça soit "automatiquement" fait par le processeur.

On m'a dit que pour les processeurs x86, il n'y a pas d'instruction pour refetcher une ligne de cache depuis la mémoire centrale, ou pour la retirer sans write-back. On m'a dit que sur x86, le processeur surveille les bus pour vérifier qu'il n'y a pas de mouvement mémoire fait par un DMA qui invaliderait les contenus des caches.

Beaucoup de "on m'a dit" comme vous pouvez le voir... Et ceux-ci me laissent perplexes: surveiller le bus me paraît cher en transistor et je vois mal ça implémenté en réalité...

Je demande donc votre aide et vos lumières éclairées!

Merci pour toute aide,
Khazna

[Obsidian]

Bonsoir,

Sans être expert de la chose, une petite recherche montre que c'est un cas de figure assez connu sous le nom de « DMA Cache Coherence », notamment ici, pour ceux qui développent des pilotes pour le noyau Linux.

En gros, la réponse est qu'il existe bien parfois des systèmes matériels d'invalidation de cache mais que la plupart du temps, « on laisse le système d'exploitation faire en sorte que cela n'arrive pas ».

Ça a du sens parce d'une part, même sur les micro-processeurs très modestes ou très anciens qui ne disposaient donc pas de mémoire cache, sil fallait quand même une broche spéciale pour pouvoir accaparer le bus le temps de l'opération (ou au moins pendant quelques cycles). C'était le cas de BusRQ sur Z80. À dire vrai, sur ces vieilles architectures, le DMA avait beaucoup de sens car le micro-processeur lui-même ne disposait pas de la puissance des puces modernes, qui peuvent presque tout émuler elles-mêmes et avoir encore du temps pour le reste. Donc, en un sens, il y a au moins un moyen de savoir que du DMA a eu lieu quelque part. Et si c'est le cas, c'est parce que l'on a programmé un matériel quelconque pour qu'il le fasse, donc sur des plages connues. Ces matériels peuvent généralement déclencher des IRQ ordinaires quand ils ont fini et, dans tous les cas, disposent quand même de flags ou de registres accessibles en lecture pour s'en informer.

En outre, sur les machines modernes, il faut composer avec la mémoire virtuelle : le DMA, par définition, s'applique directement à la mémoire physique. Or, cette mémoire est découpée en page consécutives de taille fixe, qui peuvent être réorganisées logiquement pour former des segments contigus à partir de plages qui ne le sont pas. Ceci signifie que pour qu'un processus soit impacté, il faudrait qu'il ait accès en permanence à une plage utilisée par le DMA et qui serait toujours mappée en mémoire, sans pouvoir être envoyée vers le swap pendant la durée de l'opération, et qu'il ne passe pas en mode noyau durant ce laps. Mais ça peut encore arriver…

En mode noyau, en revanche, ceux qui ont fait un tout petit peu de programmation Linux savent que le kernel dispose de son propre système d'allocation mémoire et que pour le reste, aucune routine ne peut accéder directement à « l'extérieur », c'est-à-dire à l'userspace : il faut utiliser des appels comme copy_from_user() pour le faire. Ça sert à effectuer tous les préparatifs (par exemple rapatrier la page concernée depuis le swap) qui sont transparents en temps normal… justement parce que c'est le noyau qui s'en charge ! Donc l'appel peut décider d'invalider la ligne de cache s'il l'estime nécessaire. Le noyau peut aussi choisir de marquer la page indisponible quand le périphérique DMA annonce écrire dedans de façon à s'assurer qu'un processus qui reprendrait la main et y ré-accéderait « passe bien par le guichet » avant de poursuivre ses activités.

À noter enfin que c'est vrai dans l'autre sens aussi : on pourrait penser qu'on est exonéré de la gestion de ses problèmes si le DMA ne fait que lire des données (par exemple pour interpréter un sample musical en mémoire) mais le micro-processeur peut également écrire dans sa propre mémoire cache et la mémoire principale doit donc être mise à jour en conséquence, avec sa latence. Ça voudrait donc dire que pour être sûr de ne jamais avoir d'ennuis, il faudrait en permanence synchroniser le cache avec la mémoire principale, ce qui reviendrait en fait à…*se passer de cache !

Pour toutes ces raisons, les systèmes d'exploitation préfèrent en général allouer un pool réservé aux périphériques PCI et assimilés.

[khazna]

Merci pour la réponse .

Donc peut-être que sur x86 c'est fait automatiquement...
Si quelqu'un trouve quelque chose sur ça, qui le dise noir sur blanc, je suis toujours preneur!