Я не думаю, что здесь возникает проблема с арбитражем, и для его настройки требуется поддержка платы, а также модификация ядра. Интерфейс с расширенными возможностями vc частично обрабатывается ядром Linux здесь: http://lxr.free-electrons.com/source/drivers/pci/vc.c
Я написал драйверы для пользовательских плат PCIe в Linux, и алгоритм маршрутизации трафика между платами в прошлом не проявлял себя как проблема, если только у вас нет очень необычного варианта использования - чрезвычайно длинные передачи с требованиями к задержке, близкой к реальной в реальном времени. (в этом случае вы не должны использовать PCIe).
То, что может непосредственно повлиять на этот тип производительности и куда легче обратиться, - это топология самой шины, хотя влияние, как правило, едва поддается измерению.
На компьютере запустите команду lspci как:
lspci -tv
Который покажет вам древовидное представление интерфейсов PCIe и маршрут к процессорам, которые они выбирают. В большинстве процессоров у вас будет несколько слотов, которые идут непосредственно к процессору, а другие - через мостовую микросхему (см. Набор микросхем Intel x99).
Эти мосты вводят задержку и возможность более низкой пропускной способности. CPU Direct специально настроен для высокопроизводительных устройств, таких как видеокарты. На начальном этапе, в глубине микрокода процессора могут быть оптимизации, которые еще больше ухудшают мостовые связи. Чтобы углубиться в оценку производительности и маршрутизации слотов PCIe, перейдите в раздел sysfs.
В /sys /bus /pci /slots / будет список физических слотов pci в вашей системе. В нем находится виртуальный файл, который связывает адрес шины <----> физического слота.
В каталоге /sys /bus /pci /devices находится список всех устройств (здесь lspci получает информацию).
Проходя через каждое из устройств, вы можете видеть всю информацию, представленную ядром на них, драйверы, связанные с ними, процессор, связанный с устройством (в системе с несколькими процессорами), среди прочего.
Изменить - я не упомянул некоторые очевидные вещи, которые, как я полагаю, вы исключили, но на всякий случай:
1. У обоих слотов как минимум столько же дорожек, сколько у досок?
2. Есть ли несоответствие спецификаций - например, плата pcie 3, один слот 3, а другой 2?
3. Обсуждали ли вы эту проблему с поставщиком платы и / или разработчиком драйвера, не признавая их? Они могут быть осведомлены о некоторых случайных ошибках в этом
Если вы предоставите конкретные данные, я могу дать конкретные советы.
Помимо рассмотрения топологии (это более быстрое устройство на прямом пути ЦП, в то время как другое - нет), не зная, какой тип чипсета / ЦП вы используете, я могу лишь дать общий совет, но три области, которые я бы начал искать на это:
Задержка прерывания: если прерывание для платы связано с процессором / ядром, которое обрабатывает другие устройства с высокой частотой прерываний, вы получите снижение производительности. Есть ли другие проблемы с ядром, связанные с этим ядром? смотрите / proc / interrupts, чтобы увидеть, какие другие модули ядра используют этот процессор для обработки прерываний, а также количество / скорость, с которой они происходят. Попробуйте настроить привязку ЦП для этого устройства в / proc / irw ... smp_affinity. Сходство smp - это маска, если у вас было 8 ядер и вы ничего не указали, она будет установлена в FF (8 1). Если вы установите его, например, 0x02, это заставит Core 2 обрабатывать IRQ. Если вы не знаете, что решаете конкретную проблему, форсирование этих изменений может легко усугубить ситуацию.
Поддержка прерываний. Посмотрите, использует ли одно из устройств прерывания MSI-x или MSI, а другое - стандартное (электрическое) прерывание. Иногда мосты не поддерживают реализацию MSI плат (MSI означает прерывание, сообщаемое сообщением - вместо электрического прерывания это просто пакет, который отправляется по самой шине). Если устройство обычно использует несколько прерываний, но из-за этого вынуждено работать только с одним, его может быть трудно обнаружить, если вы не ищете его напрямую, и это может вызвать проблемы с производительностью.
Охарактеризуйте производительность. В ядре много инструментов для сбора данных о производительности. Единственное, что их всех объединяет, это то, что они плохо документированы и, как правило, не поддерживаются. Но с учетом вышесказанного я хотел бы взглянуть на использование Ftrace для характеристики передачи dma с каждой платы и задержки IRQ для каждой. Вы можете получить статистическую информацию, а также конкретные сведения о событиях выбросов. Вы можете начать изучать это здесь: http://elinux.org/Ftrace
В общем, я настоятельно не рекомендую разбираться в настройках очень низкого уровня без максимально полного понимания того, что вы пытаетесь исправить (не симптомы, которые нужно исправить, а основную причину). В 99% случаев вы будете в конечном итоге поворачивать «ручки» ради этого, но не понимая, почему или какова первоначальная проблема, как можно оценить эффективность данного параметра (как немедленного, так и с точки зрения долгосрочной стабильности),
Я интенсивно использую ftrace для общей отладки ядра и очень рекомендую его. Если вы хотите немного абстрагироваться, вокруг ftrace есть обертки, которые утверждают, что упрощают использование, но я обнаружил, что дополнительная абстракция только запутывает воду - trace-cmd, акула ядра и т.д. Если вы работаете в системе red hat Вы можете посмотреть на системную карту - не то же самое, но можете предоставить аналогичные данные (и это хорошо поддерживается).
