Taille de ligne des caches L1 et L2
D'une précédente question sur ce forum, j'ai appris que, dans la plupart des systèmes de mémoire, le cache L1 est un sous-ensemble du cache L2, ce qui signifie que toute entrée supprimée de L2 est également supprimée de L1.
Alors maintenant, ma question est de savoir comment déterminer une entrée correspondante dans le cache N1 pour une entrée dans le cache N2. Les seules informations stockées dans l'entrée L2 sont les informations de balise. Sur la base de ces informations de balise, si je recrée l'adresse, elle peut s'étendre sur plusieurs lignes du cache L1 si les tailles de ligne des mémoires L1 et L2 ne sont pas identiques.
L'architecture se préoccupe-t-elle vraiment de purger les deux lignes ou maintient-elle simplement les mémoires cache L1 et L2 avec la même taille de ligne?.
Je comprends qu’il s’agit d’une décision politique, mais je veux connaître la technique couramment utilisée.
Dans Core i7, les tailles de ligne dans L1, L2 et L3 sont les mêmes: 64 octets. Je suppose que cela simplifie le maintien de la propriété inclusive et de la cohérence.
Voir page 28 de: https://www.scss.tcd.ie/Jeremy.Jones/CS3021/5%20caches.pdf
La taille des lignes de cache est (généralement) de 64 octets.
En outre, jetez un oeil à cet article très intéressant sur les caches de processeurs: Galerie des effets de cache de processeurs
Vous trouverez les chapitres suivants:
- Accès mémoire et performance
- Impact des lignes de cache
- Tailles des caches L1 et L2
- Parallélisme au niveau de l'instruction
- Associativité en cache
- Faux partage de ligne de cache
- Complexité matérielle
La technique la plus courante de gestion de la taille de bloc de cache dans une hiérarchie de cache strictement inclusive consiste à utiliser des blocs de cache de même taille pour tous les niveaux de cache pour lesquels la propriété d'inclusion est appliquée. Cela se traduit par une surcharge des étiquettes plus importante que si le cache de niveau supérieur utilisait des blocs plus grands, ce qui non seulement utilise une zone de puce, mais peut également augmenter la latence, car les caches de niveau supérieur utilisent généralement un accès en plusieurs phases (les étiquettes étant vérifiées avant l'accès à la partie de données). Cependant, cela simplifie également quelque peu la conception et réduit la capacité gaspillée des portions inutilisées des données. Il ne faut pas une fraction importante de fragments inutilisés de 64 octets dans des blocs de cache de 128 octets pour compenser la pénalité de zone d'une balise supplémentaire de 32 bits. En outre, l'effet de blocage de la mémoire cache résultant de l'exploitation d'une localité spatiale plus étendue peut être obtenu par une prélecture relativement simple, qui présente l'avantage de ne laisser aucune capacité inutilisée si le bloc voisin n'est pas chargé (pour économiser la bande passante mémoire ou réduire la latence d'une mémoire en conflit). read) et que le prélecture d’adjacence n’a pas besoin d’être limité à un plus gros morceau aligné.
Une technique moins courante divise le bloc de cache en secteurs. Le fait que la taille de secteur corresponde à la taille de bloc pour les caches de niveau inférieur évite le problème d'invalidation rétroactive excessive, car chaque secteur du cache de niveau supérieur possède son propre bit valide. (Fournir toutes les métadonnées d'état de cohérence pour chaque secteur plutôt qu'une simple validité permet d'éviter une utilisation excessive de la bande passante en écriture lorsque au moins un secteur d'un bloc n'est pas sale/modifié et qu'il existe une surcharge de cohérence [par exemple, si un secteur est à l'état partagé et qu'un autre l'est] dans l'état exclusif, une écriture sur le secteur dans l'état exclusif pourrait n'impliquer aucun trafic de cohérence, si snoopy est utilisé plutôt que la cohérence de répertoire].)
Les économies de zone réalisées grâce aux blocs de cache sectorisés étaient particulièrement importantes lorsque les étiquettes étaient sur la puce du processeur mais que les données étaient hors puce. Évidemment, si le stockage de données occupe une surface comparable à la taille de la puce du processeur (ce qui n’est pas déraisonnable), les étiquettes 32 bits avec des blocs de 64 octets occuperaient environ un 16e (environ 6%) de la surface du processeur, alors que 128 blocs d'octets prendrait la moitié autant. (Le POWER6 + d’IBM, lancé en 2009, est peut-être le processeur le plus récent à utiliser des balises sur puce et des données hors processeur. Stocker des données dans une mémoire DRAM intégrée à densité plus élevée et des balises dans une mémoire SRAM à densité plus basse, exagère effet.)
Il convient de noter qu'Intel utilise "ligne de cache" pour désigner l'unité plus petite et "secteur de cache" pour l'unité plus grande. (C’est l’une des raisons pour lesquelles j’ai utilisé "cache block" dans mon explication.) Selon la terminologie d’Intel, il serait très inhabituel que la taille des lignes de cache varie d’un niveau de cache à l’autre, que ces niveaux soient strictement inclusifs, strictement exclusifs ou utilisés. une autre politique d'inclusion.
(L'exclusion stricte utilise généralement le cache de niveau supérieur en tant que cache victime dans lequel les expulsions du cache de niveau inférieur sont insérées dans le cache de niveau supérieur. Évidemment, si la taille des blocs était différente et que la segmentation n'était pas utilisée, une expulsion exigerait le reste de le plus gros bloc à lire quelque part et invalidé s'il est présent dans le cache de niveau inférieur. [Théoriquement, une exclusion stricte pourrait être utilisée avec le contournement inflexible du cache, où une expulsion de la couche L1 contournerait L2 et aller à L3 et les erreurs de cache L1/L2 ne seraient attribuées qu'à soit L1 o L2, en contournant L1 pour certains accès. conscient que Itanium contourne L1 pour les accès en virgule flottante, mais si je me souviens bien, L2 incluait L1.])
En règle générale, dans un accès à la mémoire principale, 64 octets de données et 8 octets de parité/ECC (je ne me souviens plus exactement) sont utilisés. Et il est assez compliqué de gérer différentes tailles de lignes de cache aux différents niveaux de mémoire. Vous devez noter que la taille de la ligne de cache serait plus corrélée à la taille de l'alignement de Word sur cette architecture qu'autre chose. Sur cette base, il est très peu probable qu'une taille de ligne de cache diffère de la taille d'accès à la mémoire. Maintenant, les bits de parité sont destinés à l'utilisation du contrôleur de mémoire. La taille de la ligne de cache est donc généralement de 64 octets. Le processeur contrôle vraiment très peu au-delà des registres. Tout le reste dans l'ordinateur consiste davantage à intégrer du matériel pour optimiser les performances du processeur. Dans ce sens également, il serait insensé d'importer une complexité supplémentaire en rendant différentes tailles de lignes de cache à différents niveaux de mémoire.