Nemyslím si, že zde jde o arbitráž a úprava jejího nastavení vyžaduje podporu desky a také úpravu jádra. Rozhraní rozšířených schopností vc je částečně zpracováno v linuxovém jádře zde:http://lxr.free-electrons.com/source/drivers/pci/vc.c
Napsal jsem ovladače pro vlastní desky PCIe v Linuxu a algoritmus pro směrování provozu mezi deskami se v minulosti neukázal jako problém, pokud nemáte velmi neobvyklý případ použití - extrémně dlouhé přenosy s požadavky na latenci téměř v reálném čase. (v takovém případě byste neměli používat PCIe).
Co může přímo ovlivnit tento typ výkonu a je mnohem snadněji řešeno, je samotná topologie sběrnice, i když dopad je obvykle sotva měřitelný.
Na počítači spusťte příkaz lspci jako:
lspci -tv
Což vám ukáže stromový pohled na PCIe rozhraní a cestu k CPU, které berou. U většiny procesorů budete mít některé sloty, které jdou přímo do CPU, a jiné, které procházejí přemosťovacím čipem (viz čipová sada Intel x99
Tyto mosty zavádějí latenci a možnost pomalejší propustnosti. CPU direct je specificky nakonfigurován pro vysoce výkonná zařízení, jako jsou grafické karty. K vašemu počátečnímu bodu mohou být hluboko v mikrokódu procesoru optimalizace, které dále degradují přemostěné spoje. Chcete-li se ponořit hlouběji do hodnocení výkonu a směrování slotů PCIe, pokračujte v sysfs.
Pod /sys/bus/pci/slots/ bude seznam pci slotů (fyzických) ve vašem systému. V něm je virtuální soubor, který sdružuje adresu sběrnice <----> fyzický slot.
Pod /sys/bus/pci/devices je seznam všech zařízení (tuto informace získává lspci).
Procházením jednotlivých zařízení můžete mimo jiné vidět všechny informace vystavené jádrem, k nim přidružené ovladače, CPU přidružené k zařízení (na systému s více CPU).
Edit - nezmínil jsem některé zřejmé věci, o kterých předpokládám, že jste vyloučili, ale pro případ:
1. Mají oba různé sloty alespoň tolik drah jako desky?
2. Existuje nějaký nesoulad ve specifikaci – např. deska je pcie 3, jeden slot je 3 a druhý 2?
3. Diskutovali jste o tomto problému s dodavatelem desky a/nebo vývojářem ovladače, kromě toho, že uznali iy? Mohou si být vědomi některých náhodných chyb týkajících se toho
Pokud uvedete konkrétní podrobnosti, mohu poskytnout konkrétní radu.
Kromě toho, že se podívám na topologii (je rychlejší zařízení na přímé cestě CPU, zatímco druhé ne), neznaje typ čipové sady / CPU, který používáte, mohu nabídnout pouze obecnou radu, ale tři oblasti, které bych začal hledat v jsou:
Latence přerušení:Pokud je přerušení pro desku spojeno s CPU/jádrem, které obsluhuje jiná zařízení s vysokou mírou přerušení, dojde ke snížení výkonu. Probíhá na tomto jádru další těžké zvedání kontextu jádra? sledujte /proc/interrupts, abyste viděli, jaké další moduly jádra používají tento CPU ke zpracování přerušení a počet/rychlost, s jakou k nim dochází. Zkuste upravit afinitu CPU pro toto zařízení v /proc/irw ... smp_affinity. smp afinita je maska, pokud byste měli 8 jader a nic neuvedli, nastaví se na FF (8 1). Pokud jej nastavíte např. 0x02, což přinutí Core 2 zpracovat IRQ. Pokud nevíte, že řešíte konkrétní problém, vynucení těchto změn může situaci snadno zhoršit.
Podpora přerušení:Podívejte se, zda jedno ze zařízení používá přerušení MSI-x nebo MSI, zatímco druhé používá standardní (elektrické) přerušení. Někdy mosty nepodporují implementaci MSI desek (MSI znamená přerušení signalizované zprávou - spíše než elektrické přerušení je to jen paket, který je odeslán přes samotnou sběrnici). Pokud zařízení obvykle používá více přerušení, ale musí kvůli tomu fungovat pouze s jedním, může být obtížné jej odhalit, pokud je přímo nehledáte, a může způsobit problémy s výkonem.
Charakterizujte výkon. V jádře je mnoho nástrojů pro sběr dat o výkonu. Jedna věc, kterou mají všechny společné, je to, že jsou špatně zdokumentované a obecně nepodporované. Ale s tím, co bylo řečeno, bych se podíval na použití Ftrace k charakterizaci přenosů dma z každé desky a latence IRQ pro každou z nich. Můžete získat statistické informace i konkrétní podrobnosti o mimořádných událostech. Můžete to začít zkoumat zde:http://elinux.org/Ftrace
Obecně důrazně nedoporučuji šmejdit na velmi nízké úrovni, aniž byste co nejlépe pochopili, co se snažíte napravit (ne symptomy, které je třeba napravit, ale základní příčinu). V 99 % případů kvůli tomu budete točit „knoflíky“, ale aniž byste pochopili, proč nebo jaký je původní problém, jak lze vyhodnotit efektivitu daného nastavení (jak okamžitou, tak z hlediska dlouhodobé stability) .
Používám ftrace pro obecné ladění jádra a velmi jej doporučuji. Pokud chcete věci trochu abstrahovat, kolem ftrace jsou obaly, které tvrdí, že usnadňují použití, ale zjistil jsem, že další abstrakce jen kalí vodu - trace-cmd, kernel shark atd. Pokud používáte systém red hat můžete se podívat do systemtap - není to totéž, ale může poskytnout podobná data (a je to dobře podporováno).