Je ne pense pas que l'arbitrage soit le problème ici, et l'ajustement de ses paramètres nécessite le support de la carte ainsi que la modification du noyau. L'interface de capacité étendue vc est gérée en partie dans le noyau Linux ici :http://lxr.free-electrons.com/source/drivers/pci/vc.c
J'ai écrit des pilotes pour des cartes PCIe personnalisées sous Linux, et l'algorithme de routage du trafic entre les cartes ne s'est pas révélé être un problème dans le passé, à moins que vous n'ayez un cas d'utilisation très inhabituel - des transferts extrêmement longs avec des exigences de latence en temps quasi réel (auquel cas vous ne devriez pas utiliser PCIe).
Ce qui peut avoir un impact direct sur ce type de performances, et qui est beaucoup plus facilement traité, est la topologie du bus lui-même, bien que l'impact soit généralement à peine mesurable.
Sur la machine, exécutez la commande lspci en tant que :
lspci -tv
Ce qui vous montrera une arborescence des interfaces PCIe et la route vers le ou les processeurs qu'elles empruntent. Avec la plupart des processeurs, vous aurez des emplacements qui vont directement au CPU et d'autres qui passent par une puce de pont (voir chipset Intel x99
Ces ponts introduisent une latence et la possibilité d'un débit plus lent. Le CPU direct est spécialement configuré pour les périphériques hautes performances tels que les cartes vidéo. Pour votre point initial, au plus profond du microcode du processeur, il peut y avoir des optimisations qui dégradent davantage les liens pontés. Pour approfondir l'évaluation des performances et du routage des emplacements PCIe, continuez dans le sysfs.
Sous /sys/bus/pci/slots/ se trouve une liste des slots pci (physiques) de votre système. Il s'agit d'un fichier virtuel qui associe l'adresse du bus <----> physicalslot.
Sous /sys/bus/pci/devices se trouve une liste de tous les périphériques (c'est là que lspci obtient ses informations).
En parcourant chacun des périphériques, vous pouvez voir toutes les informations exposées par le noyau sur eux, les pilotes qui leur sont associés, le processeur associé au périphérique (sur un système à plusieurs processeurs), entre autres.
Edit - Je n'ai pas mentionné certaines choses évidentes que je suppose que vous avez exclues, mais juste au cas où :
1. Les différentes machines à sous ont-elles au moins autant de voies que les panneaux ?
2. Y a-t-il une divergence de spécifications - par exemple, la carte est pcie 3, un emplacement est 3 et l'autre 2 ?
3. Avez-vous discuté de cette préoccupation avec le fournisseur de la carte et/ou le développeur du pilote au-delà d'eux en reconnaissant que je ? Ils peuvent être au courant de certains errata aléatoires à ce sujet
Si vous fournissez des détails spécifiques, je peux fournir des conseils spécifiques.
Au-delà de regarder la topologie (est le périphérique le plus rapide sur un chemin CPU direct, tandis que l'autre ne l'est pas), ne connaissant pas le type de chipset / CPU que vous utilisez, je ne peux offrir que des conseils généraux, mais trois domaines que je commencerais à regarder à sont :
Latence d'interruption :si l'interruption de la carte est associée à un processeur/cœur qui gère d'autres périphériques avec un taux d'interruption élevé, vous subirez une baisse des performances. Y a-t-il d'autres tâches lourdes liées au contexte du noyau en cours sur ce noyau ? regardez /proc/interrupts pour voir quels autres modules du noyau utilisent ce processeur pour sa gestion des interruptions et le nombre/taux auquel elles se produisent. Essayez d'ajuster l'affinité CPU pour ce périphérique dans /proc/irw ... smp_affinity. L'affinité smp est un masque, si vous aviez 8 cœurs et que vous ne spécifiiez rien, il serait défini sur FF (8 1). Si vous le réglez sur, par ex. 0x02, qui forcera Core 2 à gérer l'IRQ. À moins que vous ne sachiez que vous traitez un problème spécifique, forcer ces changements peut facilement aggraver les choses.
Prise en charge des interruptions :jetez un coup d'œil et voyez si l'un des appareils utilise des interruptions MSI-x ou MSI, tandis que l'autre utilise une interruption (électrique) standard. Parfois, les ponts ne prennent pas en charge une implémentation MSI de cartes (MSI signifie interruption signalée par message - plutôt qu'une interruption électrique, c'est juste un paquet qui est envoyé sur le bus lui-même). Si un appareil utilise généralement plusieurs interruptions mais ne doit fonctionner qu'avec une seule pour cette raison, il peut être difficile à détecter à moins que vous ne le recherchiez directement, et cela peut entraîner des problèmes de performances.
Caractériser les performances. Il existe de nombreux outils dans le noyau pour collecter des données de performances. La seule chose qu'ils ont tous en commun est qu'ils sont mal documentés et généralement non pris en charge. Mais cela dit, j'envisagerais d'utiliser Ftrace pour caractériser les transferts dma de chaque carte et la latence IRQ pour chacune. Vous pouvez obtenir des informations statistiques ainsi que des détails spécifiques sur les événements aberrants. Vous pouvez commencer à regarder cela ici :http://elinux.org/Ftrace
En général, je déconseille fortement de faire des bêtises dans des contextes de très bas niveau sans une compréhension aussi complète que possible de ce que vous essayez de corriger (pas les symptômes à corriger, mais la cause profonde sous-jacente). 99 % du temps, vous finirez par tourner des "boutons" pour le plaisir, mais sans comprendre pourquoi ou quel est le problème d'origine, comment évaluer l'efficacité d'un réglage donné (tant dans l'immédiat qu'en termes de stabilité à long terme) .
J'utilise beaucoup ftrace pour le débogage général du noyau et je le recommande vivement. Si vous voulez que les choses soient un peu abstraites, il y a des wrappers autour de ftrace qui prétendent le rendre plus facile à utiliser, mais j'ai trouvé que l'abstraction supplémentaire ne fait que brouiller l'eau - trace-cmd, kernel shark, etc. Si vous êtes sur un système red hat vous pouvez regarder dans systemtap - pas la même chose mais peut fournir des données similaires (et c'est bien pris en charge).