Изпечатай

[buboleck]

Проблема е следния. Ядрото си е компилирано с 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

[buboleck]

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

[teleport]

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

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.

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

[buboleck]

@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 екипа го е сметнал за ненужен. Както и да е.  Отмаскирах го и съм го сложил и сега изглежда да вървят нещата както трябва.

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

[buboleck]

Странна работа при х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]

Цитат

Daemon to balance irq's across multiple CPUs on systems with the 2.4 or 2.6 kernel. This can lead to better performance and IO balance on SMP systems. Useful mostly just for 2.4 kernels, or 2.6 kernels with CONFIG_IRQBALANCE turned off.

Да не си с CONFIG_IRQBALANCE on и затова да не работи при 64 бит?

[buboleck]

@martos

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

[gat3way]

Трябва ти 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!]  */

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

[buboleck]

@gat3way

Цитат

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

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

[buboleck]

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

[gat3way]

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

[buboleck]

@gat3way

ACPI, APIC.

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

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