PDF de programación - Performance y escalabilidad del kernel Linux aplicado a redes de alta velocidad

Performance y escalabilidad del kernel Linux

aplicado a redes de alta velocidad

Abril de 2007

Resumen

Asumiendo un futuro cercano donde la compu-
tación centrada en las redes y las arquitecturas
paralelas serán características fundamentales, se
hace evidente la necesidad de replantear el diseño
del software de base teniendo en cuenta los nuevos
paradigmas de procesamiento y características del
hardware. Por un lado, se espera un gran desarro-
llo tecnológico basado en las distintas formas de
almacenamiento y procesamiento distribuido, so-
portado por el incesante avance en los estánda-
res y tecnologías de redes de datos. Por otro lado,
las arquitecturas con múltiples núcleos de proce-
samiento se están posicionando como el estándar
actual para la mayoría de las configuraciones de
hardware.

En este escenario, se están planteando nuevas
características (y adaptando antiguas ideas) que
los sistemas operativos deberán incorporar en el
corto y mediano plazo. Entre otras, se puede men-
cionar el diseño de kernels asimétricos y activos
para explotar al máximo el paralelismo en las nue-
vas arquitecturas. En este informe se describe una
modificación al diseño del subsistema de red del
kernel Linux 2.6 que permite evaluar el efecto de
hacer un uso asimétrico de los procesadores en
una máquina con arquitectura SMP asignando un
procesador de manera exclusiva al procesamiento
de red. De esta forma se intenta reducir el costo
conocido como intrusión del sistema operativo.

1.

Introducción: La intrusión del
sistema operativo

La intrusión es un nombre nuevo para un con-
cepto que existe desde que las computadoras ba-
san su funcionamiento en un proceso monitor o
sistema operativo, y representa el costo (medido
en procesamiento y almacenamiento) introducido
por el kernel al realizar sus funciones principales
de virtualización y protección de los recursos de
la máquina. Las interrupciones por hardware y las
llamadas al sistema implementadas como traps son
un ejemplo de intrusión por mecanismo (intrusión
relacionada con la implementación de las funcio-
nes del sistema operativo).

En general, el nivel de intrusión tiene una re-
lación directa con la manera en que las políticas
y mecanismos del sistema operativo se adaptan al
hardware subyacente y a la forma en que las apli-
caciones lo utilizan. Mientras que estos dos facto-
res han evolucionado notablemente en las últimas
décadas, los sistemas operativos más utilizados en
la actualidad se basan en conceptos introducidos
hace aproximadamente tres décadas (un intervalo
de tiempo enorme en lo que se refiere a tecnología
informática). Los mecanismos del kernel que de-
berían ser invocados excepcionalmente se vuelven
demasiados costosos cuando se usan con frecuen-
cias mucho más altas que aquellas para las cuales
fueron pensados. Por ejemplo, los altos costos pue-
den surgir al utilizar sistemas operativos diseñados
para tareas intensivas en computación (esto es, no

optimizados para la entrada/salida) en máquinas
cuya principal función es el movimiento de datos,
como es el caso de un Storage Element en una in-
fraestructura Grid.

Por ejemplo, en los modelos tradicionales de in-
terfaces de red, el procesador es interrumpido por
cada paquete recibido del enlace. Sin embargo, las
interfaces de alta velocidad pueden recibir miles de
paquetes por segundo1, generando miles de inte-
rrupciones (y, en consecuencia, miles de intercam-
bios de tareas) por segundo. Además de utilizar ci-
clos de procesador, las interrupciones asincrónicas
y cambios de contextos frecuentes, también causan
efectos indirectos como la polución de la memoria
cache y del Translation Lookaside Buffer (TLB),
lo que incrementa aun más el costo debido al pro-
cesamiento de red.

Los sistemas Chip Multiprocessing (CMP) y
Symmetric Multiprocessing (SMP) tienen más
probabilidades de sufrir intrusión por mecanismo,
ya que la mayoría de los sistemas operativos de
propósito general utilizados en estas máquinas,
fueron adaptados de una base monoprocesador. Por
lo tanto, además de coordinar el acceso de múlti-
ples aplicaciones independientes a un único recur-
so físico, el sistema operativo debe propagar esta
protección a lo largo de múltiples CPUs.

2. La intrusión generada por el
procesamiento TCP/IP en Li-
nux sobre SMP

2.1. Mecanismos de Linux involucrados

en el procesamiento de red

A continuación vemos como se utilizan algu-
nos conceptos de threading en el procesamiento
TCP/IP de Linux. Existe un tipo de thread especial

1A una velocidad de 10Gbps, con tramas de 1500 bytes
(12000 bits), se reciben 833.333 tramas por segundo. Esto sig-
nifica casi 1 millon de interrupciones de recepción de red por
segundo, si no se utiliza algún mecanismo de reducción de
interrupciones.

que procesa los protocolos registrados en el kernel
y se ejecuta concurrentemente con los manejadores
de interrupciones de los drivers de las NICs (Net-
work Interface Controllers). También se presentan
algunas estructuras de datos que influyen significa-
tivamente en la forma de procesar el tráfico de red
en Linux.

2.1.1.

Interrupciones y funciones diferidas

Dos de los mecanismos esenciales en la imple-
mentación del subsistema de red en el kernel Li-
nux (y en la mayoría de los sistemas operativos
modernos) son el soporte de las interrupciones por
hardware y la implementación de las funciones di-
feridas en el tiempo, conocidas generalmente co-
mo softirqs o bottom halves (no se deben confundir
con las interrupciones por software, también cono-
cidas como traps).

Cuando una señal de interrupción llega a la
CPU, el kernel debe realizar ciertas tareas que ge-
neralmente son implementadas desde el manejador
de esa interrupción. No todas las acciones a ser
realizadas tienen la misma urgencia. De hecho, el
manejador de interrupciones no es un entorno en
el que puedan realizarse cualquier tipo de acción
(por ejemplo, no se puede dormir a un proceso).
Las operaciones largas y no críticas deberían ser
diferidas ya que mientras el manejador se está eje-
cutando, el kernel está en lo que se denomina co-
mo contexto de interrupción (se le llama top half
al manejador que se ejecuta en el contexto de la
interrupción, de ahi el nombre de bottom half pa-
ra la otra parte del manejador) y la CPU que lo
ejecuta tiene deshabilitadas todas las interrupcio-
nes. Es decir, los manejadores de interrupciones
son no interrumpibles y no reentrantes (al menos
hasta que el propio manejador activa nuevamente
las interrupciones). Esta decisión de diseño ayuda
a reducir la probabilidad de condiciones de carrera,
sin embargo tiene efectos serios en la performance
si no se tiene cierto cuidado 2.

2Algunas implementaciones primitivas de TCP/IP o di-
señadas para entornos embebidos completan el procesamiento

La cantidad de procesamiento requerido por una
interrupción depende del tipo de evento que se esta
señalizando. En particular, los dispositivos de red
requieren un trabajo relativamente complejo: en el
peor de los casos3 se requiere alocar un buffer, co-
piar los datos recibidos en el mismo, inicializar al-
gunos parámetros del buffer para indicar el proto-
colo de capa dos a las capas superiores, hacer el
procesamiento de capas superiores, copiar los da-
tos al buffer del usuario, etc. Por lo tanto, y más aun
con las interfaces de red de alta velocidad actuales,
es importante consumir la menor cantidad de tiem-
po posible en los manejadores de interrupciones, o
el sistema sufrirá una perdida de capacidad de res-
puesta.

Además, TCP/IP, como otros protocolos de red,
es de naturaleza asincrónica. Básicamente, se im-
plementa como una gran máquina de estados basa-
da en un conjunto de timers. La cantidad de tiem-
po que se necesita para procesar un paquete y en-
viarlo a la capa de aplicación depende del pro-
tocolo de transporte y de muchos otros factores.
La implementación TCP/IP de Linux provee buf-
fering a varios niveles o capas, de forma tal que un
componente no retrasará a la pila entera. Por estos
motivos, es preferente permitir que la pila TCP/IP
procese los paquetes entrantes independientemente
del driver.

Aquí es donde el concepto de softirq entra en
juego. Incluso si las acciones disparadas por una
interrupción necesitan mucho tiempo de CPU, la
mayoría de estas acciones usualmente puede espe-
rar. Se define una softirq como un requerimiento
asincrónico para ejecutar una función en particu-
lar4. Este modelo permite que el kernel mantenga
las interrupciones deshabilitadas por mucho menos

de un paquete entrante en el contexto del manejador de inte-
rrupción. Sin embargo los sistemas operativos modernos sue-
len utilizar estas capacidades de threading.

3Puede haber optimizaciones para cada uno de estos pasos.
4Actualmente se utiliza la denominación de bottom half
para hacer referencia al concepto de función diferida, aunque
se implemente con otros mecanismos, como las softirqs y los
tasklets.

tiempo, y funciona siguiendo estos pasos:

El dispositivo señaliza a la CPU para notificar
de un evento.

La CPU ejecuta el top half asociado, el cual
típicamente realiza las siguientes tareas:

• Guarda en la RAM toda la información
que el kernel necesitará más tarde para
procesar el evento que interrumpió a la
CPU,

• planifica la softirq que se encargará de
procesar finalmente la interrupción con
los datos almacenados por el manejador,
• y por último rehabilita las interrupcio-

nes para la CPU local.

En algún momento en el futuro cercano, se
chequea por softirqs planificadas y se invoca a
los manejadores correspondientes en caso de
ser necesario.

A lo largo del tiempo, los desarrolladores de Li-
nux han intentado diferentes tipos de mecanismos
de bottom halves, las cuales obedecen a diferen-
tes reglas (principalmente reglas de concurrencia
y de contexto de ejecución). El subsistema de red
ha jugado un rol central en el desarrollo de nuevas
impleme