Non penso che l'arbitrato sia il problema qui e la regolazione delle sue impostazioni richiede il supporto della scheda e la modifica del kernel. L'interfaccia a capacità estesa vc è gestita in parte nel kernel linux qui:http://lxr.free-electrons.com/source/drivers/pci/vc.c
Ho scritto driver per schede PCIe personalizzate in Linux e l'algoritmo per l'instradamento del traffico tra le schede non si è rivelato un problema in passato, a meno che tu non abbia un caso d'uso molto insolito:trasferimenti estremamente lunghi con requisiti di latenza quasi in tempo reale (nel qual caso non dovresti usare PCIe).
Ciò che può avere un impatto diretto su questo tipo di prestazioni, ed è affrontato molto più facilmente, è la topologia del bus stesso, sebbene l'impatto sia solitamente appena misurabile.
Sulla macchina, esegui il comando lspci come:
lspci -tv
Che ti mostrerà una vista ad albero delle interfacce PCIe e il percorso verso le CPU che prendono. Con la maggior parte dei processori avrai alcuni slot che vanno direttamente alla CPU e altri che passano attraverso un chip bridge (vedi chipset Intel x99
Questi bridge introducono latenza e la possibilità di un throughput più lento. La CPU diretta è specificatamente configurata per dispositivi ad alte prestazioni come le schede video. Al punto iniziale, nel profondo del microcodice del processore potrebbero esserci ottimizzazioni che degradano ulteriormente i collegamenti a ponte. Per approfondire la valutazione delle prestazioni e del routing degli slot PCIe, continua nel sysfs.
Sotto /sys/bus/pci/slots/ ci sarà un elenco degli slot pci (fisici) nel tuo sistema. In esso è presente un file virtuale che associa l'indirizzo del bus <----> slot fisico.
Sotto /sys/bus/pci/devices c'è un elenco di tutti i dispositivi (qui è dove lspci ottiene le sue informazioni).
Esaminando ciascuno dei dispositivi puoi vedere tutte le informazioni esposte dal kernel su di essi, i driver ad essi associati, la CPU associata al dispositivo (su un sistema con più CPU), tra le altre cose.
Modifica:non ho menzionato alcune cose ovvie che presumo tu abbia escluso, ma per ogni evenienza:
1. I diversi slot hanno entrambi almeno tante corsie quante sono le schede?
2. C'è una discrepanza nelle specifiche, ad esempio la scheda è pcie 3, uno slot è 3 e l'altro 2?
3. Hai discusso di questo problema con il fornitore della scheda e/o con lo sviluppatore del driver oltre a loro riconoscendo iy? Potrebbero essere a conoscenza di alcuni errori casuali al riguardo
Se fornisci dettagli specifici, posso fornire consigli specifici.
Oltre a guardare la topologia (è il dispositivo più veloce su un percorso CPU diretto, mentre l'altro no), non conoscendo il tipo di chipset/CPU che stai utilizzando, posso solo offrire consigli generali, ma tre aree che inizierei a cercare a sono:
Latenza di interruzione:se l'interruzione per la scheda è associata a una CPU/core che gestisce altri dispositivi con un'elevata frequenza di interruzione, subirai un calo delle prestazioni. C'è un altro sollevamento pesante del contesto del kernel in corso su quel core? guarda /proc/interrupts per vedere quali altri moduli del kernel stanno usando quella CPU per la sua gestione degli interrupt e il conteggio/frequenza con cui si verificano. Prova a regolare l'affinità della CPU per quel dispositivo in /proc/irw ... smp_affinity. smp affinity è una maschera, se avessi 8 core e non specificassi nulla, verrebbe impostata su FF (8 1's). Se lo imposti su, ad es. 0x02, che costringerà Core 2 a gestire l'IRQ. A meno che tu non sappia che stai affrontando un problema specifico, forzare questi cambiamenti può facilmente peggiorare le cose.
Supporto di interrupt:dai un'occhiata e verifica se uno dei dispositivi utilizza interrupt MSI-x o MSI, mentre l'altro utilizza un interrupt (elettrico) standard. A volte i bridge non supportano un'implementazione MSI della scheda (MSI significa interruzione segnalata dal messaggio - piuttosto che un'interruzione elettrica è solo un pacchetto che viene inviato sul bus stesso). Se un dispositivo in genere utilizza più interrupt ma deve funzionare con uno solo per questo motivo, può essere difficile da rilevare a meno che tu non lo stia cercando direttamente e può causare problemi di prestazioni.
Caratterizzare le prestazioni. Ci sono molti strumenti nel kernel per raccogliere dati sulle prestazioni. L'unica cosa che hanno tutti in comune è che sono scarsamente documentati e generalmente non supportati. Ma detto questo, vorrei considerare l'utilizzo di Ftrace per caratterizzare i trasferimenti dma da ciascuna scheda e la latenza IRQ per ciascuno. È possibile ottenere informazioni statistiche e dettagli specifici sugli eventi anomali. Puoi iniziare a esaminarlo qui:http://elinux.org/Ftrace
In generale, sconsiglio vivamente di scherzare in contesti di livello molto basso senza una comprensione il più completa possibile di ciò che stai cercando di correggere (non i sintomi da correggere, ma la causa principale sottostante). Il 99% delle volte finirai per girare le "manopole" per il gusto di farlo, ma senza capire perché o quale sia il problema originale, come puoi valutare l'efficacia di una data impostazione (sia immediata che in termini di stabilità a lungo termine) .
Uso pesantemente ftrace per il debug generale del kernel e lo consiglio vivamente. Se vuoi che le cose siano un po' astratte, ci sono wrapper attorno a ftrace che affermano di renderlo più facile da usare, ma ho scoperto che l'astrazione aggiuntiva confonde solo l'acqua - trace-cmd, kernel shark, ecc. Se sei su un sistema red hat puoi esaminare systemtap:non è la stessa cosa ma può fornire dati simili (ed è ben supportato).