А использует ли кто irq balancing на SMP ядрах линуха

[rus-p]

На ядре 2.6.8 cat /proc/interrupts показывает

 

CPU0 CPU1

0: 694724 0 IO-APIC-edge timer

1: 1413 0 IO-APIC-edge i8042

8: 4 0 IO-APIC-edge rtc

9: 0 0 IO-APIC-level acpi

12: 58 0 IO-APIC-edge i8042

14: 41845 0 IO-APIC-edge ide0

16: 0 0 IO-APIC-level pciehp

22: 2842498 0 IO-APIC-level eth0

NMI: 0 0

LOC: 3589865 3589864

ERR: 0

MIS: 0

 

хотя smp_affinity=ff для 22 прерывания

 

В чем может быть проблема?

Ядро естественно пересобрано.

[rus-p]

Люди, может я некорректно вопрос задал?

 

Поясню. По умолчанию, линукс все прерывания от сетевухи сваливает на нулевой проц. В инете есть бурные дискуссии можно/нужно ли распределять эти прерывания от одной и той же сетевой на несколько процов.

 

Для 2.4 ядра есть патчи от Ingo, а в 2.6 уже есть опция для этого перераспределения.

 

Сейчас по топу и через /proc/interrupts вижу что жрется только первый проц.

[S_ergey]

Уменя включено.

# /etc/init.d/irqbalance status

irqbalance is running

# cat /proc/version

Linux version 2.6.12-std26-smp-alt10

# cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

0: 1390460390 1395279061 1392774968 1395519594 IO-APIC-edge timer

7: 0 0 0 0 IO-APIC-edge parport0

8: 0 0 0 1 IO-APIC-edge rtc

9: 0 0 0 1 IO-APIC-level acpi

14: 1 24991933 551 24971778 IO-APIC-edge ide0

16: 0 0 0 0 IO-APIC-level uhci_hcd:usb2

19: 0 0 0 0 IO-APIC-level uhci_hcd:usb3

23: 0 0 0 0 IO-APIC-level ehci_hcd:usb1

24: 48 0 1388458782 1 IO-APIC-level eth0

25: 2117017880 0 0 1 IO-APIC-level eth1

48: 2719 69787977 86810 70625537 IO-APIC-level aacraid

NMI: 0 0 0 0

LOC: 1279306853 1279306936 1279306842 1279306859

ERR: 0

MIS: 0

[rus-p]

Большой сенкс.

Мне со времени публикации вопроса тоже удалось кое-что выяснить.

 

Упрощенно я понимаю это так: при поступлении прерывания, управление из первичного куска кода, который всегда сидит на одном проце, кидается на нужный обработчик прерывания, который можно повесить на любой проц через smp_affinity, далее либо идет обработка в кернеле (как в rp-ppoe :-) ), либо пакет уходит в пользовательское пространство (user-level ppp). Если в кернеле, то это бабушка на двое сказала, что ядро сможет задействовать дополнительные процы, зависит от ядра и наверное от еще массы причин. Если в пользовательское пространство, то нет проблем, все процы задействованы примерно одинакого, при условии конечно многочисленности процессов. Только опять вопрос кто занимается копированием из кернела в юзерспейс и обратно скорее всего опять нулевой проц.

 

Вообщем реально, когда все крутиться в ядре и есть SMP машина, прирост с единственным экземпляром rp-pppoe у меня составил процентов эдак 20, чего и следовало ожидать. :-(

Те же 20 думаю получить компилируя UP ядро. Так что от SMP толку пока я не получил.

А ввиду ближайшей стратегии Intel к многоядерности, получается что мы в пролете.

 

Сейчас попробую помучать на предмет запуска двух серверов. Чтобы посмотреть раскидает ли ядро два сервера по разным процам. Если это случится, останется только самый первый код, который видимо уже не перераспределить. Там правда другие грабли с двумя серверами - диапазонов динамических адресов для rp-pppoe, тоже становиться два, а это ухудшает соотношение зарезервированных/использованных адресов.

 

 

 

А насчет обработки прерывания от одной сетевой сразу несколькими процами, это я похоже погорячился, не придумано такое еще, да и больно это монстрообразно будет.

Edited October 25, 2006 by rus-p