[GTER] Linux + ksoftirqd
Patrick Barreto Petronetto
patrickbp at gmail.com
Tue Jul 28 13:14:42 -03 2015
Tem essa mensagem do Marcelo Gondim aqui na lista em 2013 falando desse
problema em um concentrador PPPoE. Talvez a causa não seja a mesma, mas
acho que vale a pena analisar.
https://eng.registro.br/pipermail/gter/2013-August/044054.html
Tenho aqui um Slackware 14.1 kernel 3.10.17 (instalação full sem X,
padrão).
Ele roda umas 100 regras de iptables com conntrack ativado,
roteamento estático, pico de 90Mbps (media de 60Mbps) com 2 LAGs (bonding)
e 3 VLANs com tag passando pelos LAGs.
Hardware:
2x Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
8GB de RAM
root at fw:~# lspci | grep -i ethernet
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708
Gigabit Ethernet (rev 12)
05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708
Gigabit Ethernet (rev 12)
14:04.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5706
Gigabit Ethernet (rev 02)
15:05.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5706
Gigabit Ethernet (rev 02)
root at fw:~# cat /proc/irq/*/smp_affinity
ff
[***]
ff
ff -> significa que todas as IRQs usam todas as CPUs (e funciona bem)
root at fw:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7
0: 128 0 0 0 0 0
0 0 IO-APIC-edge timer
1: 0 0 0 1 0 0
0 1 IO-APIC-edge i8042
8: 5 7 5 9 8 10
8 7 IO-APIC-edge rtc0
9: 0 0 0 0 0 0
0 0 IO-APIC-fasteoi acpi
12: 1 1 0 0 0 2
0 0 IO-APIC-edge i8042
14: 744200 752575 746484 750328 749022 746529
749761 743207 IO-APIC-edge ata_piix
15: 0 0 0 0 0 0
0 0 IO-APIC-edge ata_piix
16: 0 0 0 0 1 0
0 1 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb6
17: 81258 80594 80849 80478 81276 80606
80881 80389 IO-APIC-fasteoi uhci_hcd:usb2
18: 0 0 0 0 0 0
0 0 IO-APIC-fasteoi uhci_hcd:usb3
19: 0 0 0 0 0 0
0 0 IO-APIC-fasteoi uhci_hcd:usb4
21: 36 34 37 37 37 35
37 38 IO-APIC-fasteoi ipmi_si
22: 13 12 10 14 11 11
11 13 IO-APIC-fasteoi hpilo, uhci_hcd:usb5
23: 0 0 0 0 0 0
0 0 IO-APIC-fasteoi radeon
64: 163481 164033 163825 164248 164308 164163
163799 164307 PCI-MSI-edge cciss0
65: 1 2 1 2 1 1
2 1 PCI-MSI-edge lpfc
66: 2842320120 2842436430 2838501766 2838028470 2837938522 2837864497
2842580968 2842399559 PCI-MSI-edge eth0
67: 2901756046 2901878051 2897844864 2897393320 2897538111 2897428373
2902334988 2902297024 PCI-MSI-edge eth1
68: 2994646768 2994540392 2998457338 2998887553 2998849741 2999012392
2994283497 2994365060 PCI-MSI-edge eth2
69: 2995417559 2995276524 2999289663 2999779197 2999782780 2999807807
2994927397 2995071716 PCI-MSI-edge eth3
NMI: 0 0 0 0 0 0
0 0 Non-maskable interrupts
LOC: 25956981 39916007 23339850 146576701 23085949 103247119
60436215 95701382 Local timer interrupts
SPU: 0 0 0 0 0 0
0 0 Spurious interrupts
PMI: 0 0 0 0 0 0
0 0 Performance monitoring interrupts
IWI: 2648544 2798925 2480895 3234953 2529771 2652096
2493552 2991598 IRQ work interrupts
RTR: 0 0 0 0 0 0
0 0 APIC ICR read retries
RES: 5148364 4728545 4555886 4943649 4861832 4874322
7383962 4903246 Rescheduling interrupts
CAL: 94519 97022 107546 238614 72072 82565
122140 169154 Function call interrupts
TLB: 159169 130669 169591 136034 226180 202110
229267 215624 TLB shootdowns
TRM: 0 0 0 0 0 0
0 0 Thermal event interrupts
THR: 0 0 0 0 0 0
0 0 Threshold APIC interrupts
MCE: 0 0 0 0 0 0
0 0 Machine check exceptions
MCP: 20419 20419 20419 20419 20419 20419
20419 20419 Machine check polls
load average: 0.00, 0.01, 0.05
A máquina fica com cpu idle em 99% a maior parte do tempo.
Um processo para cada CPU:
root at fw:~# ps aux | grep -i irq
root 3 0.0 0.0 0 0 ? S May18 0:11
[ksoftirqd/0]
root 11 0.0 0.0 0 0 ? S May18 0:13
[ksoftirqd/1]
root 15 0.0 0.0 0 0 ? S May18 0:10
[ksoftirqd/2]
root 19 0.0 0.0 0 0 ? S May18 0:19
[ksoftirqd/3]
root 23 0.0 0.0 0 0 ? S May18 0:05
[ksoftirqd/4]
root 27 0.0 0.0 0 0 ? S May18 0:13
[ksoftirqd/5]
root 31 0.0 0.0 0 0 ? S May18 1:07
[ksoftirqd/6]
root 35 0.0 0.0 0 0 ? S May18 0:07
[ksoftirqd/7]
Não estou rodando BGP nesse sistema e talvez por isso o baixo uso de
ksoftirqd.
A minha duvida é: se esse smp affinity do kernel estiver distribuído (ff)
não melhora a situação do ksoftirqd?
2015-07-28 8:29 GMT-03:00 Antonio Modesto <modesto at isimples.com.br>:
>
>
> On 07/28/15 01:00, Bruno Cabral wrote:
>
>> A história que eu conheço era que Torvalds era aluno do Tanembau, aquele
>> falou pra este que o minix era limitado, ai o Tanembaum desafiou o Torvalds
>> a fazer melhor (como eu mesmo achei um erro no livro do Tanembaum quando
>> pagava arquitetura de computadores na universidade, nem vou falar nada)
>>
>> O Tanembaum coordena hoje o desenvolvimento do Minix 3, o qual utiliza o
> conceito de microkernel que o Tanembaum defendia. Na minha opinião, olhando
> somente para a arquitetura do sistema, o modelo do Tanembaum é muito
> superior, é ridículo um S.O travar por causa de um driver que não seja
> essencial para o sistema, como audio, rede, ou dispositivos externos.
> Quanto ao BSD, eu particularmente não acho certo chamar um sistema de
> engessado por possuir um modelo de desenvolvimento totalmente organizado,
> muito diferente do que é o Linux hoje. O próprio Torvalds disse que o
> kernel do Linux está "inchado" e com funcionalidades desnecessárias, tudo
> isso devido ao modelo de desenvolvimento.
>
>> E o resultado foi que o linux está ai...
>>
>
>
>> Qual foi o 2o round?
>>
>> Sobre o modelo engessado do BSD acho que vale o artigo da catedral e do
>> bazar tanto quanto para o software proprietário, mas ai já estamos entrando
>> em outra seara
>>
>> Em tempo, eu uso linux, me atende bem, sei usar bsd e já vivi o
>> suficiente para aprender a não criticar quem usa outros def^H^H^H sistemas
>> operacionais
>>
>> ;-)
>>
>> !3runo
>>
>> Tanenbaum vs Torvalds.
>>>
>>> E em 2007, se não me engano, teve um 2º round...
>>>
>>> E eu, na minha modesta opinião, acredito que a história vem mostrando
>>> que o
>>> veinho tava certo...
>>>
>>> Analise aí exemplos de performance nas diversas áreas da T.I. e veja
>>> sobre
>>> o que essa nhaca tá rodando:
>>> Database -> hexadata
>>> Streaming -> Netflix
>>> Push -> Whatsapp
>>>
>>
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>>
>
> --
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list