прерывания на многоядерных / многопроцессорных машинах

state7401281

доброфорум!
в продолжение моего вопроса о таскменеджере из треда niman'а про атомарность - задумался, а как вобще обрабатываются аппаратные прерывания на многоядерных и/или многопроцессорных машинах (x64)?
мозг подсказывает что:
- не должно всё обрабатываться на одном ядре
- вряд ли распределяется рандомом
- вряд ли у каждого ядра своя idt
- что-то должно мочь прервать любой/все проц/ядро
может кто вкурсе?

Papazyan

- не должно всё обрабатываться на одном ядре
Почему ты так решил?
Да и как-то это малозначимо. Все равно главные события происходят в сискола/системных тредах.

state7401281

я не уверен что это так, но как бы 21й век ..
ты хочешь сказать все прерывания (~вся переферия) на одном ядре обрабатываются?

state7401281

аппаратура аппаратуре рознь, но наверное действительно это не 100% рессурса даже одного ядра, но:
а чем прерывается задача на каком-нибудь n+1 ядре (для смены контекста)?

Papazyan

В прерываниях не сидят. Если нужно что-то делать, то поднимается системный процесс, а процесс и есть процесс, выполняться может где угодно. Опять же, периферия самостоятельно умеет все делать, ей нужно только указания изредка раздавать куда писать-читать, юсб так вообще хуярит автономно по списку заданий.

smit1

я не уверен что это так, но как бы 21й век ..
Да не так это. Набери в гугле или википедии "APIC" и изучай, пока не надоест.

AlexV769

Все равно главные события происходят в сискола/системных тредах
Ой не всегда...

Marinavo_0507

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

olega

- не должно всё обрабатываться на одном ядре
Это легко проверить:

$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 156 0 0 0 IO-APIC-edge timer
1: 12 0 0 2 IO-APIC-edge i8042
7: 0 0 0 0 IO-APIC-edge parport0
8: 0 0 0 1 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 1427839 82085 791408 34848 IO-APIC-edge i8042
16: 901079 3599 111978 4523 IO-APIC-fasteoi ehci_hcd:usb1
23: 100 0 26 2 IO-APIC-fasteoi ehci_hcd:usb2
40: 642026 6191 80873 5067 PCI-MSI-edge ahci
41: 0 0 0 0 PCI-MSI-edge xhci_hcd
42: 116028 66432 625728 47491 PCI-MSI-edge i915
43: 156408 85640 822222 114994 PCI-MSI-edge eth0
44: 18 0 0 6 PCI-MSI-edge mei
45: 2 1 257 3 PCI-MSI-edge snd_hda_intel
NMI: 6973 7300 2847 3684 Non-maskable interrupts
LOC: 19660680 18061192 10586540 12676928 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 6973 7300 2847 3684 Performance monitoring interrupts
IWI: 0 0 0 0 IRQ work interrupts
RTR: 11 0 0 0 APIC ICR read retries
RES: 9907026 5449130 418932 76923 Rescheduling interrupts
CAL: 1768 1782 2098 1973 Function call interrupts
TLB: 435387 437251 356528 364054 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 962 960 960 960 Machine check polls
ERR: 0
MIS: 0

state7401281


CPU0 CPU1 CPU2 CPU3
LOC: 19660680 18061192 10586540 12676928 Local timer interrupts

но почему так сильно отличаются счётчики, для этого ведь надо или изначально завести таймер с разной частотой или переодически его перепрограммировать?

olega

Может это из-за CONFIG_NO_HZ=y?..
Но вообще странновато, да.

state7401281

btw какой uptime у этой машины был когда делал cat?

pitrik2

- не должно всё обрабатываться на одном ядре
что значит "не должно"? кому не должно?
или ты имел ввиду неэффективно?
потом про какие прерывания речь про софт или хард?
софтовыми точно можно в ядре настроить как тебе надо
хардовыми скорее всего не все настраиваются, но, многие вполне себе
по теме: см. службу irqbalancer, см. isolcpus, см. /proc/irq/*/smp_affinity
Оставить комментарий
Имя или ник:
Комментарий: