Taille des lignes des caches L1 et L2

à Partir d'un précédent question sur ce forum, j'ai appris que dans la plupart des systèmes de mémoire, le cache L1 est un sous-ensemble de la mémoire cache L2 désigne toute entrée retiré de L2 est également supprimé de L1.

donc maintenant ma question est comment déterminer une entrée correspondante dans le cache L1 pour une entrée dans le cache L2. La seule information stockée dans L'entrée L2 est l'information de l'étiquette. Basé sur cette information de balise, si je recréer l'addr il peut s'étendre à plusieurs lignes dans le cache L1 si les tailles de lignes de cache L1 et L2 ne sont pas les mêmes.

est-ce que l'architecture prend vraiment la peine de purger les deux lignes ou elle maintient juste le 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.

58
demandé sur Community 2013-02-05 16:39:38

4 réponses

dans le core i7 les tailles de ligne en L1, L2 et L3 sont les mêmes: soit 64 octets. Je suppose que cela simplifie le maintien de la propriété et de la cohérence.

voir page 28 de: https://www.scss.tcd.ie/Jeremy.Jones/CS3021/5%20caches.pdf

62
répondu Neha Karanjkar 2015-05-26 15:48:03

Cache-Lignes taille est (généralement) de 64 octets.

de plus, jetez un oeil à cet article très intéressant sur les caches des processeurs: Galerie de la mémoire Cache du Processeur d'Effets

, Vous trouverez les chapitres suivants:

  1. accès à la mémoire et performances
  2. Impact des lignes de cache
  3. tailles de cache L1 et L2
  4. l'Instruction au niveau de parallélisme
  5. associativité de Cache
  6. Faux cache le partage de la ligne
  7. complexités matérielles
58
répondu Axel Borja 2013-03-01 16:57:47

la technique la plus courante pour gérer la taille des blocs de cache dans une hiérarchie de cache strictement inclusive est d'utiliser les mêmes blocs de cache pour tous les niveaux de cache pour lesquels la propriété inclusion est appliquée. Il en résulte une plus grande portée d'étiquette que si le cache de niveau supérieur utilisait des blocs plus grands, ce qui non seulement utilise la zone de la puce, mais peut aussi augmenter la latence puisque les caches de niveau supérieur utilisent généralement l'accès par phase (où les étiquettes sont vérifiées avant que la partie des données ne soit accessible). Cependant, il a également simplifie quelque peu la conception et réduit la capacité gaspillée des parties inutilisées des données. Il n'est pas nécessaire d'utiliser une grande fraction de morceaux de 64 octets non utilisés dans les blocs de cache de 128 octets pour compenser la pénalité de zone d'une étiquette supplémentaire de 32 bits. De plus, l'effet de bloc de cache plus important de l'exploitation d'une plus grande localisation spatiale peut être fourni par un préfetching relativement simple, qui a l'avantage qu'aucune capacité n'est laissée inutilisée si le morceau voisin n'est pas chargé (pour conserver la bande passante mémoire ou réduire la latence sur une lecture de mémoire en conflit) et que le préfettage de contiguïté ne doit pas être limité à un plus grand morceau aligné.

une technique moins courante divise le bloc de cache en secteurs. Le fait que la taille du secteur soit la même que celle du bloc pour les caches de niveau inférieur évite le problème de la rétro-invalidation excessive puisque chaque secteur dans le cache de niveau supérieur a son propre bit valide. (Fournir toutes les métadonnées d'état de cohérence pour chaque secteur plutôt que la simple validité peut éviter utilisation excessive de la bande passante de réécriture lorsqu'au moins un secteur d'un bloc n'est pas sale/modifié et qu'il y a une certaine cohérence au-dessus [par exemple, si un secteur est à l'état partagé et qu'un autre est à l'état exclusif, une écriture au secteur à l'état exclusif pourrait ne pas impliquer de trafic de cohérence-si snoopy plutôt que la cohérence du répertoire est utilisée].)

les économies de zone des blocs de cache sectorisés étaient particulièrement significatives quand les étiquettes étaient sur la puce du processeur mais les données étaient hors puce. De toute évidence, si le stockage des données prend une surface comparable à la taille de la puce du processeur (ce qui n'est pas déraisonnable), alors les étiquettes de 32 bits avec des blocs de 64 octets prendraient environ un 16e (~6%) de la surface du processeur tandis que les blocs de 128 octets prendraient la moitié moins. (Le POWER6+ D'IBM, introduit en 2009, est peut-être le processeur le plus récent à utiliser sur-processeur-puce tags et données hors-processeur. Le stockage de données dans des DRAM et des tags de densité plus élevée dans des SRAM de densité plus faible, comme IBM l'a fait, exagère cet effet.)

il est à noter que Intel utilise" cache line "pour désigner la plus petite unité et" cache sector " pour la plus grande unité. (C'est une des raisons pour lesquelles j'ai utilisé "cache block" dans mon explication.) En utilisant la terminologie D'Intel, il serait très inhabituel que les lignes de cache varient en taille entre les niveaux de cache, que les niveaux soient strictement inclusifs, strictement exclusifs ou qu'ils utilisent une autre politique d'inclusion.

(l'exclusion stricte utilise généralement cache de niveau supérieur en tant que cache victime où les évictions du cache de niveau inférieur sont insérées dans le cache de niveau supérieur. De toute évidence, si la taille des blocs était différente et que la sectorisation n'était pas utilisée, alors une expulsion exigerait que le reste du gros bloc soit lu quelque part et invalidés s'ils sont présents dans le cache de niveau inférieur. [ théoriquement , l'exclusion stricte pourrait être utilisée avec le contournement de cache inflexible où une expulsion de L1 serait contourner L2 et passer à L3 et L1/L2 les erreurs de cache ne seraient attribuées qu'à soit L1 ou L2, contournant L1 pour certains accès. La plus proche de cette implémentation dont je suis au courant est le contournement de L1 par Itanium pour les accès à virgule flottante; cependant, si je me souviens bien, la L2 incluait la L1.])

19
répondu Paul A. Clayton 2014-08-13 15:00:33

typiquement, dans un accès à la mémoire principale 64 octets de données et 8 octets de parité/ECC (Je ne me souviens pas exactement lequel) est accédé. Et il est assez compliqué de maintenir 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 des mots sur cette architecture que toute autre chose. Basé sur cela, une taille de ligne de cache est très peu susceptible d'être différente de la taille d'accès à la mémoire. Maintenant, les bits de parité sont pour l'utilisation du contrôleur mémoire - donc la taille de la ligne de cache est typiquement de 64 octets. Le processeur contrôle vraiment très peu au-delà des registres. Tout ce qui se passe dans l'ordinateur est plus sur le fait d'obtenir du matériel pour optimiser les performances CPU. En ce sens aussi, il ne serait vraiment pas logique d'importer une complexité supplémentaire en faisant des tailles de lignes de cache différentes à différents niveaux de mémoire.

2
répondu RD Bhattacharya 2014-08-13 11:13:48