|
@ bjt2
Allora è come pensavo: in pratica il bug (o meglio, il workaround) rende più probabile un accesso frequente alla ram per caricare la page table. Di per sè non è una penalizzazione critica (non quanto l'altro bug), però potrebbe influenzare negativamente l'ottimizzazione dei load/store, che si basa, se ho ben compreso questa caratteristica, su un approccio conservativo che prevede proprio il calcolo dell'indirizzo effettivo. Cioè, il processore ordina gli accessi in ram, privilegiando le letture, e per farlo calcola gli indirizzi effettivi prima di un burst di accessi mixati opportunamente; ma questo vuol dire che il processore calcolerà più indirizzi prima di ogni accesso, o meglio, calcolerà tutti quelli che gli servono, in base all'algoritmo implementato, e per farlo in fretta avrà bisogno di avere le page table in cache -> più indirizzi verranno calcolati contemporaneamente e, in conseguenza al (workaround per il) bug, può aumentare la frequenza degli accessi in ram a caccia dei dati mancanti, oppure (o comunque) un solo indirizzo mancante può rallentare il riordino e l'esecuzione del burst e le operazioni da esso dipendenti (specialmente dai load). Certo, non incide come il secondo, però in alcune circostanze può essere come non avere affatto l'ottimizzazione sugli accessi (o peggio, subire una penalizzazione maggiore che non avendola).
P.S. Era venuto anche a me il dubbio che il vero problema fossero le rese e/o il tdp, e che il bug (comunque presente, ma influente più sulle prestazioni che sulla stabilità) fosse una "scusa" per rinviare i modelli superiori. In ogni caso, speriamo che risolvano e in fretta, perchè i k10 avrebbero dovuto essere a posto giù da un pezzo...
|