J'exécute quelques repères. Mon coureur de référence surveille le tampon dmesg entre les expériences, recherchant tout ce qui pourrait avoir un impact sur les performances. Aujourd'hui, il a jeté ceci:
[2015-08-17 10:20:14 ATTENTION] dmesg semble avoir changé! Le diff suit: --- 2015-08-17 09:55:00 +++ 2015-08-17 10:20:14 @@ -825,3 +825,4 @@ [3.802206] [drm] Activation des états RC6: RC6 activé, RC6p désactivé, RC6pp désactivé [7.900533] r8169 0000: 06: 00.0 eth0: liaison [7.900541] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: le lien devient prêt + [236832.221937] l'interruption perf a pris trop de temps (2504> 2500), abaissant kernel.perf_event_max_sample_rate à 50000
Après quelques recherches, je sais maintenant que cela concerne un sous-système de profilage dans le noyau Linux appelé "perf". Je ne pense pas que nous en ayons besoin, donc je voudrais le désactiver complètement.
En cherchant à nouveau, je trouve que le sysctl perf_cpu_time_max_percentpourrait aider. Ici, quelqu'un suggère de le désactiver en le mettant à 0. Lisez-en plus ici :
perf_cpu_time_max_percent:
Indique au noyau combien de temps CPU il doit être autorisé à utiliser pour gérer les événements d'échantillonnage de performances. Si le sous-système perf est informé que ses échantillons dépassent cette limite, il baissera sa fréquence d'échantillonnage pour tenter de réduire son utilisation du processeur.
Un échantillonnage de perf se produit dans les laboratoires nationaux de métrologie. Si ces échantillons prennent trop de temps à s'exécuter de manière inattendue, les NMI peuvent être empilés les uns à côté des autres à tel point que rien d'autre n'est autorisé à s'exécuter.
0: désactiver le mécanisme. Ne surveillez pas ou ne corrigez pas le taux d'échantillonnage de la performance, quel que soit le temps CPU nécessaire.
1-100: tentative de limitation du taux d'échantillonnage de perf à ce pourcentage de CPU. Remarque: le noyau calcule une longueur "attendue" de chaque événement échantillon. 100 signifie ici 100% de cette longueur attendue. Même si ce paramètre est défini sur 100, vous pouvez toujours voir la limitation de l'échantillon si cette longueur est dépassée. Réglez à 0 si vous ne vous souciez vraiment pas de la quantité de CPU consommée.
Cela me semble comme 0 signifie que la fréquence d'échantillonnage de profilage n'est plus vérifiée, mais le sous-système freq continue de fonctionner (?).
Quelqu'un peut-il nous expliquer comment désactiver complètement le profilage du noyau avec freq?
EDIT: Quelqu'un m'a suggéré d'essayer de construire un noyau sans perf, mais je ne pense pas que ce soit même possible. L'option ne semble pas commutable:
EDIT2: Après plus de lecture, j'ai décidé que je pourrais être en mesure de mettre kernel.perf_event_max_sample_rateà zéro. C'est à dire pas d'échantillons par seconde. Cependant, vous ne pouvez pas faire cela non plus ( source ):
commit 02f98e3e36da106338b7c732fed516420fb20e2a Auteur: Knut Petersen Date: mer. 25 sept. 14:29:37 2013 +0200 perf: appliquer 1 comme limite inférieure pour perf_event_max_sample_rate
EDIT 3: FWIW, perf_cpu_time_max_percentest réglé sur 25, ce qui signifie que le noyau passait plus de 25% de son temps à échantillonner les registres matériels. Ceci est inacceptable pour une machine d'analyse comparative.
Je suis maintenant certain que la mise perf_cpu_time_max_percentà zéro ne ferait qu'aggraver la situation, car le noyau continuerait à utiliser plus de 25% de son temps à lire les registres matériels. L'erreur se déclenche pour ajuster la fréquence d'échantillonnage, essayant ainsi de s'assurer que le noyau respecte son quota d'utilisation <25% de son temps en perf. 25% est encore trop élevé à mon humble avis.
Si je ne peux vraiment pas désactiver la perf, le meilleur compromis serait probablement de régler perf_event_max_sample_ratesur 1.
EDIT4: Un ami a suggéré que j'ai peut-être mal interprété le sens de perf_cpu_time_max_percent, donc les déclarations ci-dessus peuvent être incorrectes. Une valeur de 25 indique que le noyau a utilisé plus de 25% d'une longueur arbitraire qu'il avait réservée pour le service des interruptions de perf.
EDIT5:
Comme indiqué dans les commentaires, l' -*-option contre la perf suggère que la fonctionnalité est forcée par une autre fonctionnalité activée. Si je regarde helpdedans, il dit quelles sont les fonctionnalités suivantes:
Je ne pense pas pouvoir gagner ici. La formule booléenne selected bydit
Si vous ciblez X86, ou ...
Je viens de vérifier que le ciblage de X86_64 permet effectivement CONFIG_X86. Il semble donc que dès que vous ciblez X86 ou X86_64, vous obtenez la perf.
Je voudrais donc modifier légèrement ma question en:
Quels paramètres de perf puis-je utiliser pour minimiser le temps passé par le noyau dans les routines de perf?
Gardez à l'esprit que l'objectif global est de contrôler les sources de variation aléatoire pour l'analyse comparative. Si je ne peux pas désactiver la perf, comment puis-je minimiser son impact sur les benchmarks?
CONFIG_HAVE_PERF_EVENTS=yet CONFIG_PERF_EVENTS=y. Je ne pense pas que cette perf désactivée.
-*-signifie que certains sous-systèmes dépendent du module perf. Helpmontre l'arborescence des dépendances que vous devez désactiver pour changer l'option en [*]ou [M].