[GTER] Linux + ksoftirqd

[Rafael Koike]

O FreeBSD tem uma funcionalidade muito interessante chamada Polling.

*DESCRIPTION* <https://www.freebsd.org/cgi/man.cgi?query=polling&sektion=4#end>
     Device polling (*polling* for brevity) refers to a technique	that lets the
     operating system periodically poll	devices, instead of relying on the
     devices to	generate interrupts when they need attention.  This might seem
     inefficient and counterintuitive, but when	done properly, *polling* gives
     more control to the operating system on when and how to handle devices,
     with a number of advantages in terms of system responsiveness and perfor-
     mance.

     In	particular, *polling* reduces the	overhead for context switches which is
     incurred when servicing interrupts, and gives more	control	on the sched-
     uling of the CPU between various tasks (user processes, software inter-
     rupts, device handling) which ultimately reduces the chances of livelock
     in	the system.

   *Principles* *of* *Operation*
     In	the normal, interrupt-based mode, devices generate an interrupt	when-
     ever they need attention.	This in	turn causes a context switch and the
     execution of an interrupt handler which performs whatever processing is
     needed by the device.  The	duration of the	interrupt handler is poten-
     tially unbounded unless the device	driver has been	programmed with	real-
     time concerns in mind (which is generally not the case for	FreeBSD	driv-
     ers).  Furthermore, under heavy traffic load, the system might be persis-
     tently processing interrupts without being	able to	complete other work,
     either in the kernel or in	userland.

     Device polling disables interrupts	by polling devices at appropriate
     times, i.e., on clock interrupts and within the idle loop.	 This way, the
     context switch overhead is	removed.  Furthermore, the operating system
     can control accurately how	much work to spend in handling device events,
     and thus prevent livelock by reserving some amount	of CPU to other	tasks.

     Enabling *polling* also changes the way software network interrupts are
     scheduled,	so there is never the risk of livelock because packets are not
     processed to completion.

Realmente as placas de rede podem gerar muitas interrupções e isso pode
sobrecarregar a CPU e dependendo do software que estiver executando e em
qual CPU a thread do programa estiver o context switch será grande.
Como outros colegas falaram o que você deveria fazer é setar afinidade do
driver de rede E do programa que utiliza esta interface a uma mesma CPU
para diminuir o context switch.
O FreeBSD desenvolveu uma solução elegante para resolver isso.
Ao invés de dar atenção as chamadas de interrupção da placa de rede ela faz
um polling de tempos em tempos e coleta os dados que chegaram.
Claro que o tempo do polling tem que ser rápido o suficiente para não
encher o buffer da placa de rede e também não gerar atrasos no
processamento da thread.
Mas se voce considerar que o polling pode ocorrer a cada ciclo de clock ou
X milissegundos você poderá ter um tradeoff de um pequeno aumento de
latência versus um throughtput muito maior.
Sem contar que com isso poderá balancear igualmente a carga de
processamento entre múltiplas CPUs.

https://www.freebsd.org/cgi/man.cgi?query=polling&sektion=4



Em 26 de julho de 2015 13:21, Marcelo Gondim <gondim at bsdinfo.com.br>
escreveu:

> 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
>