Прерывания не разбрасываются по ядрам
/proc/irq/ /smp_affinity стоит в fff, а прерывания все почему-то на первом ядре обрабатываются:
P.S. И еще странность — если сделать к примеру echo 2 > /proc/irq/108/smp_affinity, а потом обратно echo fff > /proc/irq/108/smp_affinity, то прерывания продолжают идти только на втором ядре.
прибейте прерывание каждой очереди к отдельному ядру — это более производительео чем размазывание по всем ядрам.
Возможно, поможет демон irqbalance?
Да, я в курсе, и в итоге я этим займусь. Я не пойму почему ядро по умолчанию их не размазывает по всем ядрам. Дома у меня например сервак с тем же ядром распределяет прерывания по всем 4 ядрам равномерно.
Ну это аналог ручного управления прерываниями 🙂 Я просто хочу понять почему имея битовую маску FFF ядро всё равно лепит прерывания на 1 ядро.
какая версия ядра?
может дело в NUMA?
По идее не должно быть разницы. NUMA ведь особенность адресации памяти..
Нашел сервер с X5660 — по идее только в частоте разница, у меня похоже та же песня
Ядро 2.6.32-5-xen-amd64. Попробую еще глянуть на другой системе где тоже igb драйвер но другие процессоры, мне почему то кажется что дело в igb. Вы юзаете родной драйвер который в ванильном ядре?
Возможно что для NUMA прерывания не размазываются именно для избежания деградации производительности.
PS: На E6800 c igb 2.4.13 все размазывается. Система из прошлого моего поста работает с igb 1.3.16-k2
Cудя по пачке ifdef HAVE_DEVICE_NUMA_NODE в igb_main.c дело таки в NUMA.
ну я перед тем как написать погуглил и пришёл к выводу что это может быть связано. В инете написано что при NUMA ядро выбирается не случайно а на том на котором это быстрее всё работать будет. Лучше сам погугли, из меня плохой пересказчик.
Дело в том что не размазываются не только igb прерывания, а вообще ВСЕ. Если бы только igb, то вопросов бы не возникло. Драйвер igb я юзаю интелевский внешний, т.к. в ванильном вообще опций никаких нету, да и LRO тоже. И каждую сетевуху я опцией модуля Node= привязываю к определенной NUMA-ноде.
С одной стороны правильно, что прерывания не размазываются, т.к. если девайс будет перепрыгивать с одной ноды на другую, то будут потери в производительности. С другой стороны, в пределах каждой ноды могли бы и сделать распределение.
Нынешние процы имеют ведь встроенный контроллер памяти, и у каждого проца есть своя, локальная, память и память соседа, доступ к которой идёт через чипсет, и, соответственно, гораздо медленнее. Это и есть NUMA — каждый проц со своими мозгами — одна нода. И память устройства себе аллокируют на том или ином процессоре соответственно. Так что обработка прерываний должна идти на том проце ИМХО, где устройство угнездилось 🙂
Напутал, связь процов идёт напрямую через QPI, а не через чипсет, ну сути это не меняет.
Источник
Большие потоки трафика и управление прерываниями в Linux
В этой заметке я опишу методы увеличения производительности линуксового маршрутизатора. Для меня эта тема стала актуальна, когда проходящий сетевой трафик через один линуксовый маршрутизатор стал достаточно высоким (>150 Мбит/с, > 50 Kpps). Маршрутизатор помимо роутинга еще занимается шейпированием и выступает в качестве файрволла.
Для высоких нагрузок стоит использовать сетевые карты Intel, на базе чипсетов 82575/82576 (Gigabit), 82598/82599 (10 Gigabit), или им подобные. Их прелесть в том, что они создают восемь очередей обработки прерываний на один интерфейс – четыре на rx и четыре на tx (возможно технологии RPS/RFS, появившиеся в ядре 2.6.35 сделают то же самое и для обычных сетевых карт). Также эти чипы неплохо ускоряют обработку трафика на аппаратном уровне.
Для начала посмотрите содержимое /proc/interrupts , в этом файле можно увидеть что вызывает прерывания и какие ядра занимаются их обработкой.
В данном примере используются сетевые карты Intel 82576. Здесь видно, что сетевые прерывания распределены по ядрам равномерно. Однако, по умолчанию так не будет. Нужно раскидать прерывания по процессорам. Чтобы это сделать нужно выполнить команду echo N > /proc/irq/X/smp_affinity , где N это маска процессора (определяет какому процессору достанется прерывание), а X — номер прерывания, виден в первом столбце вывода /proc/interrupts. Чтобы определить маску процессора, нужно возвести 2 в степень cpu_N (номер процессора) и перевести в шестнадцатиричную систему. При помощи bc вычисляется так: echo «obase=16; $[2 ** $cpu_N]» | bc . В данном примере распределение прерываний было произведено следующим образом:
Также, если маршрутизатор имеет два интерфейса, один на вход, другой на выход (классическая схема), то rx с одного интерфейса следует группировать с tx другого интерфейса на одном ядре процессора. Например, в данном случае прерывания 46 (eth0-rx-0) и 59 (eth1-tx-0) были определены на одно ядро.
Еще одним весьма важным параметром является задержка между прерываниями. Посмотреть текущее значение можно при помощи ethtool -c ethN , параметры rx-usecs и tx-usecs. Чем больше значение, тем выше задержка, но тем меньше нагрузка на процессор. Пробуйте уменьшать это значение в часы пик вплоть до ноля.
При подготовке в эксплуатацию сервера с Intel Xeon E5520 (8 ядер, каждое с HyperThreading) я выбрал такую схему распределения прерываний:
/proc/interrupts на этом сервере без нагрузки можно посмотреть тут. Не привожу это в заметке из-за громоздкости
UPD:
Если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет. Однако есть параметры sysctl, которые позволяют увеличить размер кэша ARP, что может быть актуальным. При проблеме с размером ARP-кэша в dmesg будет сообщение «Neighbour table overflow».
Например:
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 4096
Описание параметров:
gc_thresh1 — минимальное количество записей, которые должны быть в ARP-кэше. Если количество записей меньше, чем это значение, то сборщик мусора не будет очищать ARP-кэш.
gc_thresh2 — мягкое ограничение количества записей в ARP-кэше. Если количество записей достигнет этого значения, то сборщик мусора запустится в течение 5 секунд.
gc_thresh3 — жесткое ограничение количества записей в ARP-кэше. Если количество записей достигнет этого значения, то сборщик мусора незамедлительно запустится.
Источник
Распределение irq: ЭТО нормально?
Решил посмотреть как распределены irq у меня в системе:
1) как я понял, у меня практически все прерывания обрабатываются одним процессором.
2) у меня на одном прерывании висят порой до трех устройств.
3) Устройства распределны по-глупому: ath (wifi который используется раз в пятилетку) занимает целый irq, тогда как два SATA винчестера висят на одном.
Посему у меня вопросы:
2) А если два процессора будут обрабатывать irq будет лучше? Как это сделать?
3) Как «вручную» распределить девайсы по irq?
Буду благодарен за такую консультацию.
>А если два процессора будут обрабатывать
то начнутся дикие race conditions и тормоза.
1. Сколько прерываний сидят на одном IRQ, не важно. Важно, сколько времени проводит процессор при обработке прерывания. А у вас, пардон, в Local timer interrupts времени потрачено в 2 раза больше, чем в обработке всех остальных прерываний вместе взятых 🙂
2. Обработчики прерываний давно уже все reentrant, то есть если одна нить зашла в него, второй нити зайти в него это не помешает. Это не MS-DOS, и не ядро 1.2, где всё ядро было одним Big Kernel Lock
3. Практически все устройства давно работают с очередями команд и активно используют DMA, так что код обработчика прерывания занимает ничтожно мало времени — отметить завершение задания, сдвинуть очередь, послать следующую команду, выйти
Так что забейте. На 386 с винтами в PIO и сетевушками NE2000 ISA это было критично. Сейчас — нет.
А как сделать чтобы IRQ обрабатывались обоими процессорами?
P. S. Сейчас у меня вот так:
Когда делаю echo 1 > /proc/irq/28/smp_affinity задействуется только первый процессор.
Когда делаю echo 2 > /proc/irq/28/smp_affinity задействуется только второй процессор.
Когда делаю echo 3 > /proc/irq/28/smp_affinity задействуется опять только первый процессор.
мне кажется зря вы этим занимаетесь, число обработаных irq у вас очень малое, имеет смысл раскидывать на разные ядра разные irq, от разных сетевых карт, жестких дисков , этим занимается irqbalance
аффинити задавать можете как уодно, все равно одновременно irq будут обработаны только одним ядром, опять таки irqbalance поможет балансировать между ядрами в зависимости от нагрузки.
какая роль вашего компьютера? для десктопа не имеет большого смысла заниматься распределением, почему — вам уже обьяснили
У меня desktop и на нем есть две проблемы, которые не дают мне покоя.
Первая — у меня периодически зависает комп и из-за чего — непонятно. В соседней ветке я уже поднимал эту тему, но четкого решения пока нет. Подозрения на видюху и на жесткий диск. А тут по IRQ оказыаюется, что они висят на одном прерывании. Я хочу копнуть туда.
Вторая проблема (которую я пока RTFMлю сам) — большая загрузка процессора при дисковых операциях. Например, при банальном забивании с помощью dd файла из /dev/zero , средняя нагрузка проца составляет 130% (то есть, например, первое ядро загружено на 80%, второе на 50% или первое на 100%, второе на 30% и т. п.). Я не верю, что с новомодными DMA, NCQ и т. п. это нормальная ситуация.
Поскольку наводящие вопросы кончились, я выслеживаю любые аномальные ситуации на компьютере, авось найду то, что решит мои проблемы.
Еще одной причиной является любознательность, которая, думается, свойствена большинству LORовцев. Так давайте разберемся вместе!
Что может быть причиной того, что у, скажем, ahonimous нагрузка по прерываниям равномерно ложится на четыре проца, а у меня только на один из двух?
>меня периодически зависает комп
большая загрузка процессора при дисковых операциях
Это у вас, очевидно, с чипсетом косяки, тут переназначать прерывания — как мёртвому припарка.
средняя нагрузка проца составляет 130%
Фактически не работает dma, но на sata dma не отключаемо, значит это аппаратный баг. Если irq разбосать по всем ядрам — то вы получите все 200%.
Под вендой таких проблем нет? Если нет — очевидно ядро не дружит с вашим дисковым контроллером пишите багрепорт.
>они висят на одном прерывании
Как выше сказано — linux != dos.
>новомодными DMA
UDMA появилось в ATA-4, это 1998 год.
>нормальная ситуация
Норма — 1-2% cpu при любых дисковых операциях.
>любые аномальные ситуации на компьютере
Меняйте материнку, винты, хренли искать.
тогда оставили бы вы эту темы с раскидыванием irq
у меня периодически зависает комп и из-за чего — непонятно
не из за irq, скорее всего какой-то кривой драйвер или acpi, обычное больное место
попробуйте acpi=off добавить в параметры ядра и сравнить как будет
(acpi=ht , если у вас процессор с HT)
вполне возможно что это видео драйвер, у меня периодически зависает ноут, ati драйвер и mesa с git’a , как откачу до стабильного снапшота так перестает зависать
А тут по IRQ оказыаюется, что они висят на одном прерывании
может быть, но решается это в bugzilla.kernel.org
для начала посмотрите какие проблемы у тех у кого похожий чипсет
средняя нагрузка проца составляет 130%
IO wait ? Опять таки стоит посмотреть что у других на том же железе, попробовать разные планировщики, я тут с NCQ обновила ядро до 34.1 и . тормозит ужасно, было лучше, вернулась на CFQ
$dd if=/dev/zero of=filetest
^C2575171+0 records in
2575171+0 records out
1318487552 bytes (1.3 GB) copied, 20.7208 s, 63.6 MB/s
Cpu0 : 4.7%us, 29.2%sy, 0.0%ni, 7.0%id, 59.1%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 2.3%us, 4.0%sy, 0.0%ni, 85.0%id, 7.6%wa, 0.0%hi, 1.0%si, 0.0%st
2258 sylvia 20 0 5636 564 476 S 35 0.0 0:06.81 dd if=/dev/zero of=filetest
тоже высокая нагрузка за счет iowait
чипсет NVidia 630i , AHCI
У моего знакомого была ситуация — под линуксом тормозили дисковые операции, венда висла, перед этим посыпался жд. Оказалось — окислились контакты на sata разъёме. Почистил — всё заработало.
[code] cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 1725148079 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 2 0 0 0 0 0 0 0 IO-APIC-edge i8042 6: 5 0 0 0 0 0 0 0 IO-APIC-edge floppy 8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc 9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi 12: 115 71 0 0 0 0 0 0 IO-APIC-edge i8042 50: 29 0 99 190 0 0 0 0 IO-APIC-level uhci_hcd:usb4 58: 13472 0 72302276 0 0 0 3219209 0 IO-APIC-level uhci_hcd:usb7, ata_piix, ata_piix 66: 412 0 0 0 0 0 0 25375026 PCI-MSI eth0 74: 207 0 0 0 0 0 0 0 IO-APIC-level HDA Intel 169: 36 2213216 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb3, uhci_hcd:usb9, ahci 225: 43 1 0 0 0 0 0 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8 233: 2 0 0 0 0 0 0 0 IO-APIC-level ehci_hcd:usb2, uhci_hcd:usb6 NMI: 258174 137248 189669 148062 255724 146964 196311 150609 LOC: 1725148018 1725147946 1725147874 1725147803 1725147701 1725147658 1725147587 1725147516 ERR: 0 MIS: 0 [/code]
Источник
