Il y a des contrôleurs mémoire qui font cette ré-écriture (opération dite de "scrubbing") automatiquement (sinon le handler EDAC devra s'en charger) quand une erreur détectée/corrigée à la volée sur un load (data) ou fetch (instruction).
Certains font même en sorte que des données (ou du code) peu utilisé ne passent pas au travers et que des erreurs single-bit/corrigibles soient alors "rattrapées par la patrouille", faute d'usage fréquent (détection/correction ne se font sinon que sur une lecture en mémoire rappelons le!), avant de potentiellement s'aggraver avec le temps en erreurs multi-bit alors non corrigibles: Cela s'appelle le "patrol scrub".
On peut aussi le faire en soft, mais que le matériel s'en charge est toujours mieux car cela n'occupe pas le processeur d'une part mais en prime le contrôleur mémoire est le mieux placé pour caser des tranches mémoire de lecture (et correction éventuelle) à un moment optimal/ou on a de la bande passante vers la DDR et donc ne pas impacter les perfs.
Pour ce patrol scrubbing, quand on l'active on a généralement un objectif de périodicité du parcours de la mémoire complet. Chez Intel c'est par défaut 24h par exemple.
Et même en cas d'erreur non corrigible, il est possible de pousser plus loin mais c'est alors des fonctionnalités OS: La zone est elle mappée par le kernel ou un process, donc utilisée? Si ce n'est pas le cas, aucun impact et on peut continuer. On peut aussi avoir encore une copie valide de la donnée, au hasard dans un cache (L1/L2 ou plateforme) et dans ce cas on a une copie valide à simplement flusher en mémoire. Au delà, si c'est dans un process applicatif on peut choisir de le tuer en moindre mal d'un reboot complet, qui dans les autres cas en règle générale s'imposera.
[^] # Re: Pourquoi le matériel ne corrige pas directement la mémoire ?
Posté par lym . En réponse à la dépêche « It works on my satellite » ou l'histoire d'un bug dans l'espace. Évalué à 4.
Il y a des contrôleurs mémoire qui font cette ré-écriture (opération dite de "scrubbing") automatiquement (sinon le handler EDAC devra s'en charger) quand une erreur détectée/corrigée à la volée sur un load (data) ou fetch (instruction).
Certains font même en sorte que des données (ou du code) peu utilisé ne passent pas au travers et que des erreurs single-bit/corrigibles soient alors "rattrapées par la patrouille", faute d'usage fréquent (détection/correction ne se font sinon que sur une lecture en mémoire rappelons le!), avant de potentiellement s'aggraver avec le temps en erreurs multi-bit alors non corrigibles: Cela s'appelle le "patrol scrub".
On peut aussi le faire en soft, mais que le matériel s'en charge est toujours mieux car cela n'occupe pas le processeur d'une part mais en prime le contrôleur mémoire est le mieux placé pour caser des tranches mémoire de lecture (et correction éventuelle) à un moment optimal/ou on a de la bande passante vers la DDR et donc ne pas impacter les perfs.
Pour ce patrol scrubbing, quand on l'active on a généralement un objectif de périodicité du parcours de la mémoire complet. Chez Intel c'est par défaut 24h par exemple.
Et même en cas d'erreur non corrigible, il est possible de pousser plus loin mais c'est alors des fonctionnalités OS: La zone est elle mappée par le kernel ou un process, donc utilisée? Si ce n'est pas le cas, aucun impact et on peut continuer. On peut aussi avoir encore une copie valide de la donnée, au hasard dans un cache (L1/L2 ou plateforme) et dans ce cas on a une copie valide à simplement flusher en mémoire. Au delà, si c'est dans un process applicatif on peut choisir de le tuer en moindre mal d'un reboot complet, qui dans les autres cas en règle générale s'imposera.