[GTER] Linux + ksoftirqd

Mon Jul 27 19:05:18 -03 2015

Tem dois cabras para quem eu sugiro que faça essa pergunta.
Um chama Stuart e o outro Benedict.

P.S.: Sempre gostei mais do careca(sem duplas interpretações, por
gentileza.)...
/*Android told-me that this text should be at bottom.*/
Em 27/07/2015 16:42, "Fernando Frediani" <fhfrediani at gmail.com> escreveu:

> Legal Raimundo.
> E por que será que até hoje não fizeram pra Linux funcionar igual funciona
> pra FreeBSD que aparentemente funciona bem melhor ?
>
> Fernando
>
> On 27/07/2015 14:22, Raimundo Santos wrote:
>
>> 2015-07-27 10:11 GMT-03:00 Fernando Frediani <fhfrediani at gmail.com>:
>>
>>  Posso estar enganado, mas a questão sobre o ksoftirqd não tem a ver
>>> também
>>> com a posição e slots que são colocadas as placas de rede e os
>>> compartilhamentos de IRQs que elas fazem entre elas e com outros
>>> dispositivos ?
>>>
>>>  Nem tanto: o ksoftirqd faz parte da arquitetura do tratamento de
>> interrupções do Linux. Qualquer periférico conectado ao computador (via
>> PCI, PCI-e, ISA ou qualquer outro modo) e que seja capaz de gerar
>> interrupções em doses cavalares, vai levar o ksoftirqd a usar muita CPU.
>>
>> Vale dar uma lida na man page do ksoftirqd.
>>
>> Uma das formas de lidar melhor com isso é configurar a afinidade daquela
>> IRQ com algum core. Por exemplo: a afinidade da porta 1 daquela placa xyz
>> fica com o core 1, a porta 2 com o core 2, e assim por diante. Mas esse
>> tipo de solução pode ser um tiro no pé: imagine os processos de roteamento
>> e encaminhamento acontecendo em outro core! Então fazer esse tunning não é
>> algo tão trivial quanto só setar a afinidade, é preciso um estudo mais
>> detalhado do que o kernel faz, de fato, com essas configurações.
>>
>> No FreeBSD, o importante é ter certeza que a afinidade da IRQ relativa a
>> interface de rede fique no mesmo processador que o processo que dela
>> depende para funcionar. No Linux, chutaria que a ideia é a mesma, mas há
>> sempre o "pequeno detalhe" da implementação no meio do caminho.
>>
>> E essa é a beleza que vejo no mundo BSD: a implementação é a mais simples
>> e
>> clara que aquele grupo (FreeBSD tem implementação diferente do OpenBSD, e
>> por aí vai) conseguiu encontrar. No Linux, em geral, é o contrário: a
>> implementação é complicada* de ler, de entender e de trabalhar com. Mas
>> isso, como dito, é a beleza que eu vejo, opinião bem pessoal.
>>
>> []s
>> Raimundo Santos
>>
>> implementação complicada*: a complicação toda que vejo no Linux não é
>> premeditada, pelo que entendo, mas sim fruto (coroláŕio?) da gana por
>> resolver todo e qualquer problema que aparece, em um único código fonte -
>> que se expõe como de propósito geral. Ora, se é propósito geral, por que
>> cuidar de cada problema específico que aparece? Algumas escolhas de
>> projeto
>> refletem no futuro, e, creio, é esse o problema com o ksoftirqd: resolvia
>> muito bem diversos problemas bem específicos com IRQs no passado, mas o
>> futuro chegou com demandas que ele não é capaz de suprir - e ainda carrega
>> uma complexidade grande consigo, dificultando a solução desse novo
>> problema.
>>
>>
>>  Fernando
>>> On 27 Jul 2015 09:43, "Kalil de A. Carvalho" <kalilac at gmail.com> wrote:
>>>
>>>  Temos suporte da RH e o que eles sugeriram, que seria recebimento de
>>>>
>>> rotas,
>>>
>>>> não batia com certos momento.
>>>>
>>>> Semana passada foi realizada uma atualização da distribuição e estamos
>>>> acompanhado para ver. Temos cinco dias de normalidade, porem estamos e
>>>> curso para propor uma substituição justamente pelo FreeBSD.
>>>>
>>>> Atenciosamente,
>>>>
>>>> 2015-07-27 8:57 GMT-03:00 Kalil de A. Carvalho <kalilac at gmail.com>:
>>>>
>>>>  Bom dia Marcelo.
>>>>>
>>>>> Estamos com um quadro semelhante: Temos um RHEL 7.0 rogando Quagga para
>>>>> fechar sessão BGP com nossas operadoras. Estavamos passando por um
>>>>>
>>>> problema
>>>>
>>>>> bastante semelhante. Em determinado momento, porem não tinha um padrão,
>>>>>
>>>> um
>>>>
>>>>> dos nossos núcleos (temos oito) ficava com uso de 100% pelo ksoftirq.
>>>>> Devido a quantidade de núcleos, repito temos oito, a carga variava
>>>>>
>>>> entre
>>>
>>>> 1
>>>>
>>>>> e 1.2. Não deveria ser um problema porem tinhamos degradação no
>>>>>
>>>> desempenho.
>>>>
>>>>> O mais estranho é que temos um hardware iqual, com o mesmo S.O.,
>>>>>
>>>> fazendo
>>>
>>>> o
>>>>
>>>>> mesmo serviço, e não passa por isso.
>>>>>
>>>>> Temos suporte da RH e o q
>>>>>
>>>>> 2015-07-26 13:21 GMT-03:00 Marcelo Gondim <gondim at bsdinfo.com.br>:
>>>>>
>>>>>  Bom dia à todos,
>>>>>>
>>>>>> Já tem alguns anos que uso FreeBSD na minha infra e não tenho nada do
>>>>>>
>>>>> que
>>>>
>>>>> reclamar quanto à isso. Tudo funciona liso e redondo mas tenho uma
>>>>>> curiosidade que sempre me segue. Na época que migrei de Linux para
>>>>>>
>>>>> FreeBSD
>>>>
>>>>> sofria em demasiado com o chamado ksoftirqd que subia à 100% quando
>>>>>>
>>>>> nosso
>>>>
>>>>> tráfego subia no horário de pico. Na época me lembro, mexi em
>>>>>>
>>>>> hardware,
>>>
>>>> kernel, tentei Debian e CentOS e nada resolvia. Vi diversos relatos na
>>>>>> Internet com o mesmo problema e hoje, depois de 5 anos foi feito algo?
>>>>>> Tenho um tráfego de quase 5Gbps hoje e fico imaginando como estaria o
>>>>>> ksoftirqd nesse momento.
>>>>>>
>>>>>> Algum amigo conseguiu essa façanha de fazer ele segurar tanto tráfego
>>>>>>
>>>>> em
>>>
>>>> algum Linux?
>>>>>>
>>>>>>
>>>>>> []'s
>>>>>> Gondim
>>>>>> --
>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Atenciosamente,
>>>>> Kalil de A. Carvalho
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Atenciosamente,
>>>> Kalil de A. Carvalho
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>>  --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter