Ich glaube nicht, dass Schiedsverfahren hier das Problem sind, und das Anpassen der Einstellungen erfordert sowohl Board-Unterstützung als auch Kernel-Modifikation. Das vc Extended Capability Interface wird hier teilweise im Linux-Kernel gehandhabt:http://lxr.free-electrons.com/source/drivers/pci/vc.c
Ich habe Treiber für benutzerdefinierte PCIe-Boards unter Linux geschrieben, und der Algorithmus zum Routing des Datenverkehrs zwischen Boards hat sich in der Vergangenheit nicht als Problem erwiesen, es sei denn, Sie haben einen sehr ungewöhnlichen Anwendungsfall – extrem lange Übertragungen mit nahezu Echtzeit-Latenzanforderungen (in diesem Fall sollten Sie PCIe nicht verwenden).
Was sich direkt auf diese Art von Leistung auswirken kann und viel einfacher angegangen wird, ist die Topologie des Busses selbst, obwohl die Auswirkungen normalerweise kaum messbar sind.
Führen Sie auf dem Computer den lspci-Befehl wie folgt aus:
lspci -tv
Dies zeigt Ihnen eine Baumansicht der PCIe-Schnittstellen und die Route zu den CPUs, die sie nehmen. Bei den meisten Prozessoren haben Sie einige Steckplätze, die direkt zur CPU gehen, und andere, die über einen Brückenchip gehen (siehe Intel x99-Chipsatz
Diese Brücken führen zu Latenz und der Möglichkeit eines langsameren Durchsatzes. Die CPU direkt ist speziell für Hochleistungsgeräte wie Grafikkarten konfiguriert. Zu Ihrem Ausgangspunkt kann es tief im Mikrocode des Prozessors Optimierungen geben, die die überbrückten Verbindungen weiter beeinträchtigen. Weitere Informationen zur Bewertung der Leistung und des Routings der PCIe-Steckplätze finden Sie in den sysfs.
Unter /sys/bus/pci/slots/ finden Sie eine Liste der PCI-Slots (physisch) in Ihrem System. Darin befindet sich eine virtuelle Datei, die Busadresse <----> physischer Steckplatz zuordnet.
Unter /sys/bus/pci/devices befindet sich eine Liste aller Geräte (hier bekommt lspci seine Informationen).
Wenn Sie jedes der Geräte durchgehen, können Sie unter anderem alle Informationen sehen, die der Kernel auf ihnen offenlegt, die damit verbundenen Treiber, die mit dem Gerät verbundene CPU (bei Systemen mit mehreren CPUs).
Bearbeiten - Ich habe einige offensichtliche Dinge nicht erwähnt, von denen ich annehme, dass Sie sie ausgeschlossen haben, aber nur für den Fall:
1. Haben die verschiedenen Slots beide mindestens so viele Bahnen wie die Boards?
2. Gibt es eine Spezifikationsabweichung - z. B. ist das Board PCIe 3, ein Steckplatz ist 3 und der andere 2?
3. Haben Sie diese Bedenken mit dem Board-Hersteller und/oder dem Treiberentwickler besprochen, ohne dass sie dies bestätigt haben? Sie kennen möglicherweise einige zufällige Errata diesbezüglich
Wenn Sie konkrete Angaben machen, kann ich Sie konkret beraten.
Abgesehen von der Betrachtung der Topologie (ist das schnellere Gerät auf einem direkten CPU-Pfad, das andere nicht) und kenne den verwendeten Chipsatz / CPU-Typ nicht, kann ich nur allgemeine Ratschläge geben, aber drei Bereiche, in denen ich anfangen würde zu suchen bei sind:
Interrupt-Latenz:Wenn der Interrupt für das Board mit einer CPU/einem Kern verbunden ist, der andere Geräte mit einer hohen Interrupt-Rate verarbeitet, werden Sie einen Leistungseinbruch erleiden. Gibt es auf diesem Kern ein anderes schweres Heben des Kernel-Kontexts? Beobachten Sie /proc/interrupts, um zu sehen, welche anderen Kernelmodule diese CPU für ihre Interrupt-Behandlung und die Anzahl/Rate, mit der sie auftreten, verwenden. Versuchen Sie, die CPU-Affinität für dieses Gerät in /proc/irw ... smp_affinity anzupassen. smp-Affinität ist eine Maske, wenn Sie 8 Kerne hätten und nichts angeben würden, würde sie auf FF (8 Einsen) gesetzt werden. Wenn Sie es einstellen, z. 0x02, das zwingt Core 2, den IRQ zu handhaben. Wenn Sie nicht wissen, dass es sich um ein bestimmtes Problem handelt, kann das Erzwingen dieser Änderungen die Situation leicht verschlimmern.
Interrupt-Unterstützung:Sehen Sie nach, ob eines der Geräte MSI-x- oder MSI-Interrupts verwendet, während das andere einen (elektrischen) Standard-Interrupt verwendet. Manchmal unterstützen Bridges keine MSI-Implementierung auf einer Platine (MSI bedeutet Message Signaled Interrupt - anstatt eines elektrischen Interrupts ist es nur ein Paket, das über den Bus selbst gesendet wird). Wenn ein Gerät normalerweise mehrere Interrupts verwendet, aber aus diesem Grund nur mit einem einzigen arbeiten muss, kann es schwer zu erkennen sein, es sei denn, Sie suchen direkt danach, und es kann zu Leistungsproblemen kommen.
Leistung charakterisieren. Es gibt viele Tools im Kernel, um Leistungsdaten zu sammeln. Allen gemeinsam ist, dass sie schlecht dokumentiert sind und im Allgemeinen nicht unterstützt werden. Aber nachdem dies gesagt wurde, würde ich die Verwendung von Ftrace in Betracht ziehen, um die DMA-Übertragungen von jedem Board und die IRQ-Latenz für jedes Board zu charakterisieren. Sie können statistische Informationen sowie spezifische Details zu Ausreißerereignissen abrufen. Sie können sich hier damit befassen:http://elinux.org/Ftrace
Im Allgemeinen rate ich dringend davon ab, in sehr niedrigen Einstellungen herumzuspielen, ohne ein möglichst vollständiges Verständnis dessen zu haben, was Sie zu korrigieren versuchen (nicht die zu korrigierenden Symptome, sondern die zugrunde liegende Ursache). In 99 % der Fälle werden Sie am Ende an „Knöpfen“ drehen, aber ohne zu verstehen, warum oder was das ursprüngliche Problem ist, wie können Sie die Wirksamkeit einer bestimmten Einstellung bewerten (sowohl unmittelbar als auch in Bezug auf die Langzeitstabilität). .
Ich verwende ftrace stark für das allgemeine Kernel-Debugging und kann es nur empfehlen. Wenn Sie möchten, dass die Dinge ein wenig abstrahiert werden, gibt es Wrapper um ftrace, die behaupten, es einfacher zu verwenden, aber ich fand, dass die zusätzliche Abstraktion nur das Wasser trübt - Trace-cmd, Kernel Shark usw. Wenn Sie auf einem Red-Hat-System sind Sie können in systemtap nachsehen - nicht dasselbe, kann aber ähnliche Daten liefern (und es wird gut unterstützt).