Nous exécutons un processus en temps réel sur un noyau non temps réel (CentOS 6), et cela ne va probablement pas changer.
Nous avons une application de streaming vidéo qui nécessite environ 500 Mo / s de trafic PCIe à partir d'un FPGA personnalisé en continu pendant 1,5 heure à la fois. L'application fonctionne plutôt bien - la plupart du temps. Cependant, nous avons eu des situations où il semble que le noyau cesse de répondre aux demandes de maintenance PCIe ou de mémoire pendant jusqu'à 500 millisecondes à la fois. Cela semble se produire pendant les E / S de fichiers en rafale à partir d'un autre thread. J'ai trouvé impossible d'essayer de reproduire ce problème en faisant simplement beaucoup d'E / S de fichiers factices à partir de l'espace utilisateur pendant que l'application principale est en cours d'exécution.
Existe-t-il un moyen de forcer (simuler) un "gel" global du noyau Linux (en particulier, arrêter PCIe ou tous les accès à la mémoire DDR3 ou quelque chose comme ça) afin que nous puissions reproduire ce problème?
Nous avons mis en mémoire tampon jusqu'à 10 millisecondes en ce moment dans la mémoire FPGA interne, mais ce n'est pas suffisant. Nous pouvons mettre en mémoire tampon sur FPGA DDR3 puis vider sur l'hôte, mais nous avons besoin d'une méthode pour tester cette nouvelle fonctionnalité sous la contrainte.
Nous ne voulons pas que le noyau se fige ou se bloque définitivement. Nous aimerions pouvoir définir l'intervalle de temps.
Je cherche quelque chose dans le sens d'écrire /proc/sys/vm
temporairement des valeurs magiques qui rend le système pratiquement ramper, puis revenir en arrière après quelques centaines de millisecondes, mais regarder le nombre de façons possibles de le casser n'est pas pour un débutant comme moi ( https://www.kernel.org/doc/Documentation/sysctl/vm.txt ). Peut-être un peu de numactl
magie?