Cycles perdus sur Intel? Une incohérence entre rdtsc et CPU CLK UNHALTED.REF TSC
Sur les processeurs récents (au moins la dernière décennie) Intel a offert trois compteurs de performance matérielle à fonction fixe, en plus de divers compteurs de performance configurables. Les trois compteurs fixes sont:
INST_RETIRED.ANY
CPU_CLK_UNHALTED.THREAD
CPU_CLK_UNHALTED.REF_TSC
Le premier compte les instructions retirées, le deuxième nombre de cycles réels, et le dernier est ce qui nous intéresse. La description du Volume 3 du manuel des développeurs de logiciels Intel est la suivante:
Cet événement compte le nombre de cycles de référence au Taux de TSC quand le noyau n'est pas dans un État d'arrêt et non dans un État D'arrêt TM. Le core entre dans l'état d'arrêt lorsqu'il exécute l'instruction HLT ou le MWAIT instruction. Cet événement n'est pas affecté par la fréquence de base changements (par exemple, p États) mais compte à la même fréquence que le temps stamp counter. Cet événement peut approximer le temps écoulé pendant que le noyau n'était pas dans un État d'arrêt et non dans un État TM stopclock.
Donc, pour une boucle liée au processeur, Je m'attends à ce que cette valeur être identique à la valeur TSC libre lue à partir de rdstc, car elles ne devraient diverger que pour les instructions de cycles arrêtés ou ce qu'est "L'état TM stopclock".
Je teste ceci avec la boucle suivante (toute la démo autonome est disponible sur github):
for (int i = 0; i < 100; i++) {
PFC_CNT cnt[7] = {};
int64_t start = nanos();
PFCSTART(cnt);
int64_t tsc =__rdtsc();
busy_loop(CALIBRATION_LOOPS);
PFCEND(cnt);
int64_t tsc_delta = __rdtsc() - tsc;
int64_t nanos_delta = nanos() - start;
printf(CPU_W "d" REF_W ".2f" TSC_W ".2f" MHZ_W ".2f" RAT_W ".6fn",
sched_getcpu(),
1000.0 * cnt[PFC_FIXEDCNT_CPU_CLK_REF_TSC] / nanos_delta,
1000.0 * tsc_delta / nanos_delta,
1000.0 * CALIBRATION_LOOPS / nanos_delta,
1.0 * cnt[PFC_FIXEDCNT_CPU_CLK_REF_TSC]/tsc_delta);
}
La seule chose importante dans la région chronométrée est busy_loop(CALIBRATION_LOOPS); qui est simplement une boucle serrée de magasins volatils, qui Comme compilé par gcc et clang s'exécute à un cycle par itération sur récent matériel:
void busy_loop(uint64_t iters) {
volatile int sink;
do {
sink = 0;
} while (--iters > 0);
(void)sink;
}
Les commandes PFCSTART et PFCEND lisent le compteur CPU_CLK_UNHALTED.REF_TSC en utilisant libpfc. Le __rdtsc() est un intrinsèque qui lit le TSC via l'instruction rdtsc. Enfin, nous mesurons le temps réel avec nanos() qui est simplement:
int64_t nanos() {
auto t = std::chrono::high_resolution_clock::now();
return std::chrono::time_point_cast<std::chrono::nanoseconds>(t).time_since_epoch().count();
}
Oui, je n'émet pas de cpuid, et les choses ne sont pas entrelacées de manière exacte, mais la boucle d'étalonnage est une seconde complète, donc de tels problèmes à l'échelle de la nanoseconde se diluent à plus ou moins rien.
Avec TurboBoost activé, voici les premiers résultats d'une exécution typique sur mon processeur Skylake i7-6700HQ:
CPU# REF_TSC rdtsc Eff Mhz Ratio
0 2392.05 2591.76 2981.30 0.922946
0 2381.74 2591.79 3032.86 0.918955
0 2399.12 2591.79 3032.50 0.925660
0 2385.04 2591.79 3010.58 0.920230
0 2378.39 2591.79 3010.21 0.917663
0 2355.84 2591.77 2928.96 0.908970
0 2364.99 2591.79 2942.32 0.912492
0 2339.64 2591.77 2935.36 0.902720
0 2366.43 2591.79 3022.08 0.913049
0 2401.93 2591.79 3023.52 0.926747
0 2452.87 2591.78 3070.91 0.946400
0 2350.06 2591.79 2961.93 0.906733
0 2340.44 2591.79 2897.58 0.903020
0 2403.22 2591.79 2944.77 0.927246
0 2394.10 2591.79 3059.58 0.923723
0 2359.69 2591.78 2957.79 0.910449
0 2353.33 2591.79 2916.39 0.907992
0 2339.58 2591.79 2951.62 0.902690
0 2395.82 2591.79 3017.59 0.924389
0 2353.47 2591.79 2937.82 0.908047
Ici, {[17] } est le compteur de performances TSC fixe comme décrit ci-dessus, et rdtsc est le résultat de l'instruction rdtsc. {[20] } est la fréquence réelle calculée effective du processeur sur l'intervalle et est principalement montrée par curiosité et comme une confirmation rapide de la quantité de turbo. Ratio est le rapport des colonnes REF_TSC et rdtsc. Je m'attendrais à ce que ce soit très proche de 1, mais en pratique, nous voyons qu'il oscille autour de 0.90 à 0.92 avec beaucoup de variance (Je l'ai vu aussi bas que 0.8 sur d'autres courses).
Graphiquement, cela ressemble à ceci2:
L'appel rdstc renvoie des résultats presque exacts 1, alors que le compteur PMU TSC est partout, parfois presque aussi bas que 2300 MHz.
Si je désactiver turbo , cependant, les résultats sont beaucoup plus cohérence:
CPU# REF_TSC rdtsc Eff Mhz Ratio
0 2592.26 2592.25 2588.30 1.000000
0 2592.26 2592.26 2591.11 1.000000
0 2592.26 2592.26 2590.40 1.000000
0 2592.25 2592.25 2590.43 1.000000
0 2592.26 2592.26 2590.75 1.000000
0 2592.26 2592.26 2590.05 1.000000
0 2592.25 2592.25 2590.04 1.000000
0 2592.24 2592.24 2590.86 1.000000
0 2592.25 2592.25 2590.35 1.000000
0 2592.25 2592.25 2591.32 1.000000
0 2592.25 2592.25 2590.63 1.000000
0 2592.25 2592.25 2590.87 1.000000
0 2592.25 2592.25 2590.77 1.000000
0 2592.25 2592.25 2590.64 1.000000
0 2592.24 2592.24 2590.30 1.000000
0 2592.23 2592.23 2589.64 1.000000
0 2592.23 2592.23 2590.83 1.000000
0 2592.23 2592.23 2590.49 1.000000
0 2592.23 2592.23 2590.78 1.000000
0 2592.23 2592.23 2590.84 1.000000
0 2592.22 2592.22 2588.80 1.000000
Fondamentalement, le rapport est de 1,000000 à 6 décimales .
Graphiquement (avec l'échelle de l'axe Y forcée d'être la même que le graphique précédent):
Maintenant, le code exécute juste une boucle chaude, et il ne devrait pas y avoir d'instructions hlt ou mwait, certainement rien qui impliquerait une variation de plus de 10%. Je ne peux pas dire à coup sûr quels sont les "cycles D'horloge D'arrêt TM", mais je parie qu'ils sont " thermiques gestion des cycles d'arrêt d'horloge", une astuce utilisée pour étrangler temporairement le CPU lorsqu'il atteint sa température maximale. Cependant, j'ai regardé les lectures de thermistance intégrées, et je n'ai jamais vu le CPU casser 60C, bien en dessous du 90C-100C où la gestion termal entre en jeu (je pense).
Une idée de ce que cela pourrait être? Y a-t-il des "cycles d'arrêt" implicites pour faire la transition entre différentes fréquences turbo? Cela se produit certainement puisque la boîte n'est pas calme et donc la fréquence turbo saute de haut en bas comme d'autres cœurs démarrent et arrêtent de travailler sur des choses d'arrière-plan (la fréquence turbo max dépend directement du nombre de cœurs actifs: sur ma boîte, il est 3.5, 3.3, 3.2, 3.1 GHz pour 1, 2, 3 ou 4 cœurs actifs, respectivement).
1 En fait, pendant un moment j'ai vraiment été prise en exacte résultats à deux décimales: 2591.97 MHz - itération après itération. Puis quelque chose a changé et je ne suis pas exactement sûr de quoi et il y a une petite variation d'environ 0.1% dans les résultats rdstc. Un la possibilité est un ajustement progressif de l'horloge, effectué par le sous-système de synchronisation Linux pour aligner le temps dérivé du cristal local avec le temps déterminé ntpd. Peut - être, c'est juste une dérive de cristal-le dernier graphique ci-dessus montre une augmentation constante de la période mesurée de rdtsc chaque seconde.
2 les graphiques ne correspondent pas aux mêmes exécutions que les valeurs affichées dans le texte car je ne vais pas mettre à jour les graphiques chaque fois que je change le format de sortie de texte. Le le comportement qualitatif est essentiellement le même à chaque course, cependant.
1 réponses
TL; DR
L'écart que vous observez entre RDTSC et {[8] } est dû aux transitions D'État P de TurboBoost. Au cours de ces transitions, la majeure partie du noyau, y compris le compteur de performance à fonction fixe REF_TSC, est arrêtée pendant environ 20000-21000 cycles (8,5 us), mais rdtsc continue à sa fréquence invariante. {[10] } est probablement dans un domaine de puissance et d'horloge isolé parce qu'il est si important et à cause de son comportement documenté de type wallclock.
Le RDTSC-REFTSC écart
L'écart se manifeste par une tendance de RDTSC à surcompter REFTSC. Plus le programme est long, plus la différence RDTSC-REFTSC a tendance à être positive. Sur de très longues étendues, il peut monter aussi haut que 1% -2% ou même plus.
Bien sûr, il a déjà été observé par vous - même que le surcomptage disparaît lorsque TurboBoost est désactivé, ce qui peut être fait comme suit lors de l'utilisation de intel_pstate:
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
Mais cela ne nous dit pas avec certitude que TurboBoost est responsable de l'écart; il se pourrait que les États p plus élevés activés par TurboBoost mangent la marge disponible, provoquant des étranglements thermiques et des arrêts.
Limitation Possible?
TurboBoost est une solution dynamique de mise à l'échelle de la fréquence et de la tension pour tirer parti de manière opportuniste de la marge de manœuvre dans l'enveloppe de fonctionnement (thermique ou électrique). Lorsque cela est possible, TurboBoost va alors augmenter la fréquence de base et la tension du processeur au-delà de leur nominale valeur, améliorant ainsi les performances au détriment de la consommation électrique supérieure.
La consommation d'énergie plus élevée augmente bien sûr la température du noyau et la consommation d'énergie. Finalement, une sorte de limite sera atteinte, et TurboBoost devra réduire les performances.
TM1 limitation thermique?
J'ai commencé par étudier si les circuits de commande thermique (TCC) du moniteur thermique 1 (TM1) ou 2 (TM2) provoquaient un étranglement thermique. TM1 réduit la consommation d'énergie par l'insertion de cycles D'arrêt D'horloge TM, et ce sont l'une des conditions documentées pour conduire à un arrêt de REFTSC. TM2, d'autre part, ne porte pas l'horloge; il met seulement à l'échelle la fréquence.
J'ai modifié libpfc() pour me permettre de lire sélectionnez Msr, plus précisément le IA32_PACKAGE_THERM_STATUS et IA32_THERM_STATUS Msr. Les deux contiennent un État en lecture seule et un indicateur de journal en lecture-écriture, matériel-collant pour diverses conditions thermiques:
(le registre
IA32_PACKAGE_THERM_STATUSest sensiblement le même)
Alors que certains de ces bits étaient à l'occasion fixés (en particulier lors du blocage des Bouches d'aération d'ordinateur portable!), ils ne semblaient pas corréler avec RDTSC surcomptage, qui se produirait de manière fiable quel que soit l'état thermique.
Cyclisme De Service De Matériel? C-Résidence D'État?
En creusant ailleurs dans le SDM pour le matériel de type stop-clock, je suis arrivé sur HDC (Hardware Duty Cycle), un mécanisme par lequel le système d'exploitation peut demander manuellement à la CPU de n'utiliser qu'un HDC met en œuvre cela en exécutant le processeur pour 1-15 cycles d'horloge par période de 16 heures, et force-ralenti pour les 15-1 cycles d'horloge restants de cette période.
HDC propose des registres très utiles, en particulier les MSRs:
-
IA32_THREAD_STALL: compte le nombre de cycles bloqués en raison du ralenti forcé sur ce processeur logique. -
MSR_CORE_HDC_RESIDENCY: identique à ci-dessus mais pour le processeur physique, compte les cycles lorsqu'un ou plusieurs les processeurs de ce noyau sont au ralenti. -
MSR_PKG_HDC_SHALLOW_RESIDENCY: compte les cycles que le paquet était dans L'état C2 et qu'au moins un processeur logique était en marche forcée. -
MSR_PKG_HDC_DEEP_RESIDENCY: compte les cycles que le paquet était dans un État C plus profond (qui est précisément configurable) et qu'au moins un processeur logique était au ralenti par la force.
Pour plus de détails, reportez-vous à Intel SDM Volume 3, Chapitre 14, §14.5.1 interface de programmation de cycle de service Matériel.
Mais mon processeur i7-4700MQ 2.4 GHz ne prend pas en charge le HDC, et c'était donc cela pour le HDC.
Autres Sources D'étranglement?
Creuser un peu plus encore dans le SDM Intel j'ai trouvé untrès, très juicy MSR: MSR_CORE_PERF_LIMIT_REASONS. Ce registre rapporte un grand nombre d'états très utiles et de bits de journal collants:
690H MSR_CORE_PERF_LIMIT_REASONS-Package-indicateur de coupure de fréquence dans les cœurs de processeur
- Bits
0: PROCHOT Statut- Bits
1: Le Statut Thermique- Bits
4: Pilote Graphique Statut. Lorsqu'elle est définie, la fréquence est réduite en dessous de la demande du système d'exploitation en raison du remplacement du pilote graphique du processeur.- Bit
5: Statut De Contrôle De Fréquence Autonome Basé Sur L'Utilisation . Lorsqu'elle est définie, la fréquence est réduite en dessous de la demande du système d'exploitation, car le processeur a détecté une faible utilisation.- Bits
6: État D'Alerte Thermique Du Régulateur De Tension . Lorsqu'il est réglé, la fréquence est réduite en dessous de la demande du système d'exploitation en raison d'une alerte thermique du régulateur de tension.- Bit
8: État Du Point De Conception Électrique . Lorsqu'elle est réglée, la fréquence est réduite en dessous de la demande du système d'exploitation en raison de contraintes de point de conception électrique (par exemple, la consommation de courant électrique maximale).- Bit
9: État De Limitation De Puissance De Base . Lorsqu'il est réglé, la fréquence est réduit en dessous de la demande du système d'exploitation en raison de la limitation de puissance au niveau du domaine.- Bit
10: statut PL1 de limitation de puissance au niveau du paquet . Lorsqu'elle est définie, la fréquence est réduite en dessous de la demande du système d'exploitation en raison de la limitation de puissance au niveau du package PL1.- Bit
11: statut PL2 de limitation de puissance au niveau du paquet . Lorsqu'elle est définie, la fréquence est réduite en dessous de la demande du système d'exploitation en raison de la limitation de puissance au niveau du package PL2.- Bits
12: Max Turbo Limiter Le Statut De. Lorsqu'elle est définie, la fréquence est réduite en dessous de la demande du système d'exploitation en raison des limites turbo Multi-core.- Bit
13: Statut D'Atténuation De Transition Turbo . Lorsqu'il est réglé, la fréquence est réduite en dessous de la demande du système d'exploitation en raison de L'atténuation de transition Turbo. Cela empêche la dégradation des performances due aux changements fréquents du rapport de fonctionnement.- Bit
16: JOURNAL DE PROCHOT- Bits
17: Thermique Log- Bit
20: Journal Du Pilote Graphique- Bit
21: Journal De Contrôle De Fréquence Autonome Basé Sur L'Utilisation- Bit
22: Journal D'Alerte Thermique Du Régulateur De Tension- Bit
24: Conception Électrique Point Journal- Bit
25: Journal De Limitation De Puissance De Base- Bit
26: package-niveau limitation de puissance PL1 Log- Bits
27: limite de puissance au niveau du paquet PL2 Log- Bit
28: Max Turbo Limite Journal- Bit
29: Log D'Atténuation De Transition Turbo
pfc.ko supporte maintenant ce MSR, et un demo imprime lequel de ces bits de journal est actif. Le pilote pfc.ko efface les bits collants à chaque lecture.
Je redirige vos expériences lors de l'impression des bits, et mes rapports CPU sous une charge très lourde (tous les 4 cœurs / 8 fils actifs) plusieurs facteurs limitatifs, y compris point de conception électrique et limite de puissance de base. Les bits PL2 au niveau du paquet et Max Turbo Limit sont toujours définis sur mon processeur pour des raisons inconnues. J'ai aussi vu à l'occasion atténuation de transition Turbo .
Alors qu'aucun de ces bits ne correspondait exactement à la présence de la divergence RDTSC-REFTSC, Le Dernier bit m'a donné matière à réflexion. La simple existence de L'atténuation de transition Turbo implique que la commutation des États P a un coût suffisamment important pour qu'elle soit limitée au taux avec un mécanisme d'hystérésis. Quand je ne pouvais pas trouver un MSR qui comptait ces transitions, j'ai décidé de faire la meilleure chose-je vais utiliser l'ampleur du surcompte RDTSC-REFTSC pour caractériser les implications de performance d'une transition TurboBoost.
Expérience
La configuration de l'expérience est la suivante. Sur mon processeur i7-4700MQ, vitesse nominale 2,4 GHz et max Turbo Speed 3.4 GHz, je vais déconnecter tous les cœurs sauf 0 (le processeur de démarrage) et 3 (un noyau de victime pratique non numéroté 0 et non un frère logique de 0). Nous demanderons alors au pilote intel_pstate de nous donner une performance de paquet de pas moins de 98% et pas plus de 100%; cela contraint le processeur à osciller entre le deuxième état P le plus élevé et le plus élevé (3,3 GHz et 3,4 GHz). Je fais ceci comme suit:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu4/online
echo 0 > /sys/devices/system/cpu/cpu5/online
echo 0 > /sys/devices/system/cpu/cpu6/online
echo 0 > /sys/devices/system/cpu/cpu7/online
echo 98 > /sys/devices/system/cpu/intel_pstate/min_perf_pct
echo 100 > /sys/devices/system/cpu/intel_pstate/max_perf_pct
, j'ai couru le démo application de 10000 les échantillons à
1000, 1500, 2500, 4000, 6300,
10000, 15000, 25000, 40000, 63000,
100000, 150000, 250000, 400000, 630000,
1000000, 1500000, 2500000, 4000000, 6300000,
10000000, 15000000, 25000000, 40000000, 63000000
Nanosecondes par add_calibration() exécuté à la fréquence nominale du processeur (multipliez les nombres ci - dessus par 2,4 pour obtenir l'argument réel à add_calibration()).
Résultats
Cela produit des journaux qui ressemblent à ceci (cas de 250000 nanos):
CPU 0, measured CLK_REF_TSC MHz : 2392.56
CPU 0, measured rdtsc MHz : 2392.46
CPU 0, measured add MHz : 3286.30
CPU 0, measured XREF_CLK time (s) : 0.00018200
CPU 0, measured delta time (s) : 0.00018258
CPU 0, measured tsc_delta time (s) : 0.00018200
CPU 0, ratio ref_tsc :ref_xclk : 24.00131868
CPU 0, ratio ref_core:ref_xclk : 33.00071429
CPU 0, ratio rdtsc :ref_xclk : 24.00032967
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : -18
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018001000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz : 2392.63
CPU 0, measured rdtsc MHz : 2392.62
CPU 0, measured add MHz : 3288.03
CPU 0, measured XREF_CLK time (s) : 0.00018192
CPU 0, measured delta time (s) : 0.00018248
CPU 0, measured tsc_delta time (s) : 0.00018192
CPU 0, ratio ref_tsc :ref_xclk : 24.00000000
CPU 0, ratio ref_core:ref_xclk : 32.99983509
CPU 0, ratio rdtsc :ref_xclk : 23.99989006
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : -2
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018001000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz : 2284.69
CPU 0, measured rdtsc MHz : 2392.63
CPU 0, measured add MHz : 3151.99
CPU 0, measured XREF_CLK time (s) : 0.00018121
CPU 0, measured delta time (s) : 0.00019036
CPU 0, measured tsc_delta time (s) : 0.00018977
CPU 0, ratio ref_tsc :ref_xclk : 24.00000000
CPU 0, ratio ref_core:ref_xclk : 33.38540919
CPU 0, ratio rdtsc :ref_xclk : 25.13393301
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : 20548
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018000000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz : 2392.46
CPU 0, measured rdtsc MHz : 2392.45
CPU 0, measured add MHz : 3287.80
CPU 0, measured XREF_CLK time (s) : 0.00018192
CPU 0, measured delta time (s) : 0.00018249
CPU 0, measured tsc_delta time (s) : 0.00018192
CPU 0, ratio ref_tsc :ref_xclk : 24.00000000
CPU 0, ratio ref_core:ref_xclk : 32.99978012
CPU 0, ratio rdtsc :ref_xclk : 23.99989006
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : -2
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018001000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
J'ai fait plusieurs observations sur les bûches, mais une s'est détachée:
Pour les nanos ~ 250000, on peut observer de manière fiable l'horloge de surcomptage cycle de quanta d'un peu plus de 20000 cycles d'horloge. Mais ils sont pas en raison des transitions Utilisateur-OS.
Voici un tracé visuel:
Points bleus saturés: 0 écarts-types (proche de la moyenne)
Points rouges saturés: + 3 écarts types (au-dessus de la moyenne)
Points verts saturés: -3 écarts types (en dessous de la moyenne)
Il y a une différence marquée avant, pendant et après environ 250000 nanosecondes de décrémentation soutenue.
Nanos
Avant le seuil, les journaux CSV ressemblent à ceci:
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,-4,3639,1
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-44,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,12,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,32,3171,1
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
Indiquant un rapport TurboBoost parfaitement stable à 33x, un {[7] } qui compte en synchronisation avec REFTSC à 24x le taux de REF_XCLK (100 MHz), surcomptage négligeable, typiquement 0 cycles passés dans le noyau et donc 0 transitions dans le noyau. Les interruptions du noyau prennent environ 3000 cycles de référence.
Nanos == 250000
Au seuil critique, le journal contient des touffes de 20000 surcounts de cycle, et les surcounts sont très bien corrélés avec des valeurs de multiplicateurs estimés non entiers entre 33x et 34x:
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,2,0,0
24.00,33.00,24.00,22,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.05,25.11,20396,0,0
24.00,33.38,25.12,20212,0,0
24.00,33.39,25.12,20308,0,0
24.00,33.42,25.12,20296,0,0
24.00,33.43,25.11,20158,0,0
24.00,33.43,25.11,20178,0,0
24.00,33.00,24.00,-4,0,0
24.00,33.00,24.00,20,3920,1
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-4,0,0
24.00,33.44,25.13,20396,0,0
24.00,33.46,25.11,20156,0,0
24.00,33.46,25.12,20268,0,0
24.00,33.41,25.12,20322,0,0
24.00,33.40,25.11,20216,0,0
24.00,33.46,25.12,20168,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,22,0,0
Nanos > 250000
LE TurboBoost de 3,3 GHz à 3,4 GHz se produit maintenant de manière fiable. Au fur et à mesure que les nanos augmentent, les journaux sont remplis de multiples à peu près entiers de quanta de 20000 cycles. Finalement il y a tellement de nanos que les interruptions du planificateur Linux deviennent permanentes appareils, mais la préemption est facilement détectée avec les compteurs de performance, et son effet n'est pas du tout similaire aux arrêts TurboBoost.
24.00,33.75,24.45,20166,0,0
24.00,33.78,24.45,20302,0,0
24.00,33.78,24.45,20202,0,0
24.00,33.68,24.91,41082,0,0
24.00,33.31,24.90,40998,0,0
24.00,33.70,25.30,58986,3668,1
24.00,33.74,24.42,18798,0,0
24.00,33.74,24.45,20172,0,0
24.00,33.77,24.45,20156,0,0
24.00,33.78,24.45,20258,0,0
24.00,33.78,24.45,20240,0,0
24.00,33.77,24.42,18826,0,0
24.00,33.75,24.45,20372,0,0
24.00,33.76,24.42,18798,4081,1
24.00,33.74,24.41,18460,0,0
24.00,33.75,24.45,20234,0,0
24.00,33.77,24.45,20284,0,0
24.00,33.78,24.45,20150,0,0
24.00,33.78,24.45,20314,0,0
24.00,33.78,24.42,18766,0,0
24.00,33.71,25.36,61608,0,0
24.00,33.76,24.45,20336,0,0
24.00,33.78,24.45,20234,0,0
24.00,33.78,24.45,20210,0,0
24.00,33.78,24.45,20210,0,0
24.00,33.00,24.00,-10,0,0
24.00,33.00,24.00,4,0,0
24.00,33.00,24.00,18,0,0
24.00,33.00,24.00,2,4132,1
24.00,33.00,24.00,44,0,0
Conclusions
La Machine TurboBoost est responsable de l'écart dans RDTSC-REFTSC. Cet écart peut être utilisé pour déterminer qu'une transition D'État TurboBoost de 3,3 GHz à 3,4 GHz prend environ 20500 cycles d'horloge de référence (8,5 us), et est déclenchée au plus tard environ 250000 ns (250us; 600000 cycles d'horloge de référence) après l'entrée dans add_reference(), lorsque le processeur décide que la charge de travail est suffisamment intense pour mériter une mise à l'échelle fréquence-tension.
Travaux Futurs
D'autres recherches doivent être effectuées pour déterminer comment le coût de transition varie en fonction de la fréquence et si le matériel sélectionnant l'état d'alimentation peut être réglé. Les "unités D'atténuation Turbo", dont j'ai vu des indices dans les confins du web, m'intéressent particulièrement. Peut-être que le matériel Turbo a un configurable timewindow? Actuellement, le rapport entre le temps passé à décider et le temps passé à transitionner est de 30: 1 (600us: 20us). Peut-il être réglé?