[GTER] Linux + ksoftirqd
Marcelo Gondim
gondim at bsdinfo.com.br
Tue Jul 28 16:24:20 -03 2015
On 28-07-2015 13:14, Patrick Barreto Petronetto wrote:
> 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
Esse foi um outro problema que tive montando um concentrador PPPoE com
Linux. Mas foi apenas para testes.
A ideia era trocar os concentradores PPPoE em RouterOS por soluções
GNU/Linux limpas.
Atualmente estamos para montar o mesmo em FreeBSD usando a solução do
meu amigo Tiago Felipe [1]
[1] ftp://ftp.registro.br/pub/gter/gter38/03-PPPoE.pdf
>
> 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
>>>>
More information about the gter
mailing list