[GTER] Linux + ksoftirqd

[Raimundo Santos]

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
>