Linux за българи: Форуми

Проблема е следния. Ядрото си е компилирано с SMP, имам двуядрен Athlon64, но /proc/interrupts изглежда така:
           CPU0       CPU1
  0:    4517643          0    IO-APIC-edge  timer
  1:       9178          0    IO-APIC-edge  i8042
  6:          3          0    IO-APIC-edge  floppy
  8:          0          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 12:     245141          0    IO-APIC-edge  i8042
 14:        202          0    IO-APIC-edge  ide0
 50:     421282          0   IO-APIC-level  libata, ehci_hcd:usb2
 58:        303          0   IO-APIC-level  libata, HDA Intel
 66:          0          0   IO-APIC-level  libata
 74:          0          0   IO-APIC-level  cx88[0]
 82:      40624          0       PCI-MSI-X  eth0
 90:       7697          0       PCI-MSI-X  eth0
 98:     411264          0       PCI-MSI-X  eth0
106:     385258          0   IO-APIC-level  nvidia
233:          0          0   IO-APIC-level  ohci_hcd:usb1
NMI:       1699       1342
LOC:    4516796    4516916
ERR:          0
MIS:          0

т.е. има прекъсвания само на едното ядро. Как да го накарам да ги балансира?

Трябва дадено irq да го набуташ в другия процсор. Като слагаш определена стройност на irq за да слуша на едина или дрига стойност в зависимост кой/кои процесори ще ползваш

пробвай....

echo 2 > /proc/icq/106/името-на-файла-но-не-си-спомням-как-се-казваше

файла е  /proc/irq/номерче/smp_affinity

а стойноста се определя така:
               Binary       Hex
    CPU 0    0001         1
    CPU 1    0010         2
    CPU 2    0100         4
    CPU 3    1000         8

GigaVolt мерси, само че това е твърдо закачане на irq към процесор. Има ли някъкъв софт който да го прави динамично?. И още един въпрос. Ако не пускам "irq balance" това ще доведе ли до спад на производителността при компилиране например? Т.е. при операции касаещи предимно процесорите.

Не видях да е споменат кернела, но ето при мен как изглежда:

Centos 3.8, kernel: 2.4.21-47.ELsmp

# cat /proc/interrupts
           CPU0       CPU1
  0:    2447896    2445608    IO-APIC-edge  timer
  1:          2          0    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  8:          1          0    IO-APIC-edge  rtc
 16:         54  278192296   IO-APIC-level  eth0
 17:  287649474          0   IO-APIC-level  eth1
 19:      13212      73058   IO-APIC-level  libata
NMI:          0          0
LOC:    4893197    4893195
ERR:          0
MIS:          0

# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:04 init
    2 ?        SW     0:00 [migration/0]
    3 ?        SW     0:00 [migration/1]
    4 ?        SW     0:00 [keventd]
    5 ?        SWN    0:00 [ksoftirqd/0]
    6 ?        SWN    0:00 [ksoftirqd/1]
    9 ?        SW     0:00 [bdflush]
    7 ?        SW     0:00 [kswapd]
    8 ?        SW     0:00 [kscand]
   10 ?        SW     0:00 [kupdated]
   11 ?        SW     0:00 [mdrecoveryd]
   19 ?        SW     0:00 [scsi_eh_0]
   20 ?        SW     0:00 [scsi_eh_1]
   23 ?        SW     0:03 [kjournald]
  346 ?        SW     0:00 [kjournald]
  691 ?        S      0:01 syslogd -m 0
  695 ?        S      0:00 klogd -x
  705 ?        S      0:01 irqbalance

Дано това да помогне да се разбере какво липсва.

PS: Видях нещо странно:

...
82:      40624          0       PCI-MSI-X  eth0
90:       7697          0       PCI-MSI-X  eth0
98:     411264          0       PCI-MSI-X  eth0
...
NMI:       1699       1342
...

Странно защо eth0 е закачена към 3 прекъсвания едновременно и защо има NMI прекъсвания?

# cat /proc/interrupts | grep NMI
NMI:          0          0
# uptime
 23:13:27  up 99 days,  9:22,  1 user,  load average: 0.00, 0.00, 0.00

Намерих и това: http://www.linux-tutorial.info/modules....eid=116

Цитат

When a parity error occurs in memory, the state of the system is uncertain. To prevent any further problems, the parity checking logic generates a Non-maskable Interrupt (NMI), and the CPU immediately jumps to special codes called NMI service routines. When Linux is interrupted with an NMI as the result of a parity error, it too realizes things are not good, and the system panics. The panic causes the system to stop everything and shut down.

Дали пък нямаш някакви хардуерни проблеми?

@teleport
Ядрото е 2.6.18-rc6 (след като преди това пуснах 2.6.17). Ами липсва ми irqbalance което ти имаш (това е допълнителен софтуер който се занимава с разпределяне на прекъсванията). Мислех, че ядрото се занимава с тия неща ама не. А това:

82:      40624          0       PCI-MSI-X  eth0
90:       7697          0       PCI-MSI-X  eth0
98:     411264          0       PCI-MSI-X  eth0

е заради "Message Signaled Interrupts (MSI and MSI-X)" което бях компилирал (до сега не ми беше правило такива неща). В Gentoo има пакет за х86 на irqbalance, но не и за amd64, а и видях в changelog-a за пакета, че amd64 екипа го е сметнал за ненужен. Както и да е.  Отмаскирах го и съм го сложил и сега изглежда да вървят нещата както трябва.

Мерси за идеите и помоща на всички.

Странна работа при х86 ядро е това:
cat /proc/interrupts
           CPU0       CPU1
  0:     866785     842970     IO-APIC-edge  timer
  1:       1341       1314        IO-APIC-edge  i8042
  8:          1          1         IO-APIC-edge  rtc
  9:          0          0         IO-APIC-level  acpi
 12:      88045      84376    IO-APIC-edge  i8042
 14:        391        111      IO-APIC-edge  ide0
 16:      40059      45426   IO-APIC-level  libata, ohci_hcd:usb1
 17:          0          0        IO-APIC-level  libata, ehci_hcd:usb2
 18:        405        143      IO-APIC-level  libata, HDA Intel
 19:     198946          1     IO-APIC-level  eth0
 20:          0          0        IO-APIC-level  cx88[0]
 21:      76656      76215   IO-APIC-level  nvidia
NMI:          0          0
LOC:    1709717    1709672
ERR:          0
MIS:          0

а при х86_64 е по-горе... Май нещо не бачка като хората на 64 бита.

@martos

Не изобщо нямам CONFIG_IRQBALANCE в конфигурацията. Нещо друго е. Ще го боря като имам време. За сега карам на х86.

Трябва ти X86_IO_APIC подръжка в ядрото, виж дали не буут-ваш с noapic също така, защото това не е ли изпълнено, дори да си го компилирал с irq balancing, няма да сработи.

Сега да обясня вижданията си по въпроса Има няколко варианта за "балансиране" на прекъсванията:

1) Всички прекъсвания се изпълняват на първия процесор (цпу0) - както е в случая. Всъщност, това не е толкова лошо, из мейлинг листите на кърнъл девелоперите съм виждал статии които адвокатстват за това решение. Чел съм че в определени случаи това е по-добрият вариант (при интелски процесори с много кеш).

2) Набиваш през /proc твърдо кое прекъсване на кой процесор се изпълнява. На мен лично този вариант най-много ми допада, особено ако става въпрос примерно за рутер с 2 интерфейса през който минава повечко трафик...или пък ИДЕ райд масив

3) kernel IRQ balancing - в ядрата 2.6, дам. Не мисля че това е кой знае колко добра идея, особено що се отнася до един процесор с няколко ядра, според мен единствено ще донесе повече overhead.

4) userspace-ска джаджа (като irqbalance) която прави същото - според мен е абсолютна глупост при 2.6 ядра.

---------

Що се отнася до NMIs, при х86_64 по дефолт ядрата се компилират с NMI watchdog. Всяка секунда таймера генерира NMI. В ядрото има една проверка ако 5 секунди броят на NMI прекъсванията върху един процесор не се увеличават, тогава определено има проблем, съответно излиза онзи лош екран Oops...като се издъмпва съдържанието на стека и регистрите за да може някой брадат мустакат кърнъл девелопер да си поблъска главата защо се случва това (все пак кода за х86_64 е доста по-"млад" от този за i386...)

Ако разгледате файла nmi.c вътре си го пише в един коментар...

Цитат

/*  * the best way to detect whether a CPU has a 'hard lockup' problem  * is to check it's local APIC timer IRQ counts. If they are not  * changing then that CPU has some problem.  *  * as these watchdog NMI IRQs are generated on every CPU, we only  * have to check the current processor.  *  * since NMIs don't listen to _any_ locks, we have to be extremely  * careful not to rely on unsafe variables. The printk might lock  * up though, so we have to break up any console locks first ...  * [when there will be more tty-related locks, break them up  *  here too!]  */

Това предполагам генерира известно забавяне, тъй като всяка секунда се обработва това прекъсване, но вероятно е пренебрежително малко.

@gat3way

Цитат

Трябва ти X86_IO_APIC подръжка в ядрото, виж дали не буут-ваш с noapic също така, защото това не е ли изпълнено, дори да си го компилирал с irq balancing, няма да сработи.

Всичко това е както трябва. Проблема е САМО при 64 битово ядро.

След малко разследване, изглежда проблема е софтуерен   с корени в BIOS-a. Знаех си че не трябва да купувам ASUS.

Хм, любопитно ми е, какво точно се оказа в БИОС-а?

@gat3way

ACPI, APIC.

За проба инсталирах и виндовс хп. Не иска и да разбере, че процесора е с две ядра. Ако го принудя да се инсталира като Multiprocesor просто забива при същинската инсталация. Така че нищо друго не остава освен да e проблем в BIOS-a.

И между другото с последния BIOS съм. Ще се чакат поправки, които май ще са много.