PDF de programación - Sistemas Operativos y Redes de alta velocidad

Sistemas Operativos y Redes de alta velocidad

Matías Zabaljáuregui

Introducción

Contexto

Algunos Problemas

Contexto – Futuro Cercano

The Tera Era

“An age when people need teraflops of computing power,
terabits of communication bandwidth, and terabytes of data

storage to handle the information all around them”

(Intel)

Contexto – Factores Fundamentales

Computación Centrada en las Redes

Arquitecturas SMP / Multicore

Contexto – Computación Centrada en las Redes

Tecnología de Comunicaciones, se vuelven soluciones de
backplane:

Infiniband, Fibre Channel, Myrinet...

Ethernet 100 Gbps

Distribución de datos, procesadores e instrumentos

WWW y Web Services
HPC, e-science, grid y cloud computing
Almacenamiento (SAN, NAS)
Multimedia, sensores, RFID, etc

Contexto – Arquitecturas SMP / Multicore

Servidores

Xeon® processor family
Itanium® 2 processor

Escritorios

Consolas de Juegos

Cell (IBM, Sony y Toshiba)

Dispositivos embebidos

Core™2 Extreme processor

Core™2 Duo E6400 y
T7400

Dispositivos de Red

Experimentales

IXP2855 Network Processor

Intel Teraflops Research
Chip (80 cores)

Algunos Problemas

Limitaciones de las plataformas actuales

El software debe ser re-diseñado

Proyección de mejoras en RED, CPU y RAM

fuente: INTEL - Accelerating High Speed Networking

Algunos Problemas – Limitaciones de Plataforma

La barrera de la memoria principal: John von Neumann. 1946.
"The Principles of Large-Scale Computing Machines"

TCP/IP es una flow application: no aprovecha localidades espaciales
o temporales de las referencias

Las placas de red como dispositivos periféricos: El
problema de la última milla en las LANs

Cuellos de botella de SMP / Multicore: Arquitecturas donde
“todo se comparte”: CPUs, memoria, buses, periféricos, el propio
kernel, etc.

Algunos Problemas – El software

Software de usuario

Escalabilidad no suficiente de los procesos servidores

Sistemas Operativos

Kernel para SMP/CMP adaptado de kernel UP

Diseño y arquitectura de TCP/IP históricamente
incluida en el kernel (que generalmente está más orientado a
fairness que a E/S)

Interrupciones y modelos tradicionales de drivers con NICs muy
rápidas (10 / 100 Gbps)

Operaciones con sockets implementadas como system calls

Semántica UNIX obliga a implementaciones poco eficientes.

Algunos Problemas – El kernel

Interrupciones

Sincronización

Copias de datos en
memoria

Scheduling

Intrusión del

Sistema Operativo

En esta charla vamos a

Repasar la evolución de la arquitectura de los kernels,
principalmente en el entorno académico
Estudiar el codiseño hardware/software del subsistema de red en
un servidor SMP con Ethernet Gigabit y el kernel Linux 2.6
Identificar y clasificar los costos que reducen la performance y/o
escalabilidad del kernel Linux en el procesamiento de red
Analizar las soluciones propuestas hasta ahora en el ámbito
académico e industrial
Estudiar la posibilidad de adaptar la idea de un kernel activo para
mejorar la performance y escalabilidad del subsistema de red del
kernel Linux

Intrusión del Sistema Operativo

El rol del Sistema Operativo

La Intrusión del Sistema Operativo

La evolución de los Sistemas Operativos

El rol del Sistema Operativo – Virtualización

Protección: prevenir accesos inválidos a los recursos

Multiplexación: virtualizaciones independientes de un
recurso físico

Traducción: mapear instancias virtualizadas al recurso
subyacente

Por ejemplo, consideremos la memoria virtual

Fueron combinadas con las funciones de alto nivel →

intrusión del sistema operativo

La Intrusión del Sistema Operativo – Conceptos

Es el overhead generado por el sistema operativo al
cumplir con sus funciones de protección, virtualización y
traducción.

Tiene una relación directa con la forma en que las
polítivas y mecanismos del sistema operativo se adaptan
al uso que las aplicaciones hacen del mismo.

La Intrusión del Sistema Operativo – Clasificación

Intrusión por recursos: memoria, bloques de disco, ancho
de banda, etc.

Intrusión por tiempo

Intrusión por política : un caso de estudio notable, readahead

Intrusión por mecanismo

protección implementada particionando dominio de ejecución
se vuelve necesario cruzar los límites de privilegios
intrusión sincrónica e intrusión asincrónica
intrusión en SMP, por ejemplo: Big Kernel Lock

La Intrusión del Sistema Operativo – FI

Factor de Intrusión

tiempo real de ejecución
----------------------------------
tiempo ideal de ejecución

Caso Ideal

FI == 1

Livelock

FI == ∞

Un poco de historia UNIX

1970 MIT, Multics incluye la primer pila de red, ARPAnet.

2 minutos para paginar pero el kernel no paginaba

entonces la pila de protocolos tuvo que ser incluida en el kernel

1980, se implementa TCP/IP en Multics
1983, la misma gente (BBN) implementa TCP/IP en BSD
1985, BSD 4.1 usa la pila de BBN como referencia
1987, se libera el código con licensia BSD
1989, SVR4: AT&T y Sun
1991 Linux: Linus Torvalds Intel 386 (i386)

La evolución – Kernel Monolítico

La virtualización es
implementada a través de la
abstracción

Un único espacio de
direccionamiento

TCP/IP incluído en el kernel por
herencia de Multics

La evolución – Microkernel

Servicios del sistema operativo en

procesos servers

El kernel implementa sólo un

mínimo de servicios de virtualización

El sistema operativo puede

ofrecer diferentes estrategias

Los requerimientos de E/S y los

datos asociados deben cruzar límites
de protección adicionales

La evolución – Kernel Vertical

El kernel provee primitivas de
virtualización de bajo nivel a las
aplicaciones

Las aplicaciones pueden

implementar sus propias funciones
de alto nivel

Sin procesos Servers

intermediarios. Se evita el IPC

Las librerías compartidas son
una parte integral de este tipo de
sistema

La evolución – Kernel Activo

El kernel se ejecuta
continuamente en un
procesador dedicado

Eliminación de las
interrupciones asincrónicas (se
reduce el overhead y la
complejidad del código)

Objetos en memoria compartida
como el mecanismo principal de
comunicación entre las
aplicaciones y el kernel

Piglet, 2001

Performance en el procesamiento de red

Temas de hardware

Subsistema de red de Linux 2.6

Los costos del procesamiento de red

Temas de hardware

Network Interface Controllers (NICs)

Tecnología de buses de E/S

La latencia de la memoria principal y la inefectividad de la
memoria cache

Network Interface Controllers (NICs)

Tecnología de buses de E/S

PCI

Latencia ≈ 500 ns
4 Ghz -> 4 ciclos / ns
32 bits a 33 MHz --> 1056 Mbps
Latencia ≈ 2000 ciclos

PCI 2.2

64 bits a 66 MHz --> 4256 Mbps

PCI-X

64 bits a 133 MHz --> 8,48 Gbps

PCI-X 2.0

64 bits a 266 MHz --> 16 Gbps
64 bits a 533 MHz --> 32 Gbps

PCI Express

1X = 2,5 gbps ..... 32X = 80 gbps

fuente: http://zone.ni.com/devzone/cda/tut/p/id/5805

La latencia de la memoria principal y
la inefectividad de la memoria cache

Latencia de memoria principal

Accesos de TCP/IP a memoria principal

Inefectividad de la memoria cache

Regla “1 GHz / 1 Gbps”

Latencia de memoria principal

La performance de DRAM se caracteriza por su latencia
de acceso (ha mejorado sólo a un 7% anual)

CPUs de 4 GHz vs bus de memoria de 400 MHz
(DDR2-800)

DDR2 es conocido por sus altas latencias de lectura, que
llegan a ser de hasta 9 ciclos del bus de memoria

Se requiere tiempo adicional para atravesar el bus de
memoria, el northbridge y FSB hasta el procesador

Accesos de TCP/IP a memoria principal

El ancho de banda de memoria principal en las

computadoras modernas de propósito general está en el
mismo orden que el ancho de banda de las redes de alta
velocidad emergentes

El camino de datos de toda transferencia por red
involucra al menos tres accesos a memoria principal.

Son cinco accesos en el peor caso (tamaño de los
paquetes vs tamaño de cache)

Inefectividad de la memoria cache

TCP/IP es una Flow Application

Polución de cache

Tamaño de la Cache y Correspondencia

Política de escritura y mecanismos de coherencia

Latencias de DRAM actuales

fuente: http://www.sharkyextreme.com/hardware/cpu/article.php/3261_3641516__5

Regla “1 GHz / 1 Gbps”

Esta relación empeora para transferencias con unidades
más pequeñas.

Tomando medidas a dos frecuencias de CPU (800 MHz y
2.4 GHz) se ha mostrado que la performance de red sólo
escala en un 60 %

La tecnología SMT ayuda a disminuir los ciclos de CPU
ociosos en los accesos a memoria de las aplicaciones
con más de un thread de ejecución

Subsistema de red de Linux 2.6

Mecanismos de Linux involucrados en el procesamiento
de red

Componentes del procesamiento TCP/IP

Mecanismos de Linux involucrados en el procesamiento de

red

Interrupciones y funciones diferibles

Los threads del kernel y ksoftirqd

La estructrura softnet_data

Los socket buffers

Interrupciones y funciones diferibles

El manejador de interrupciones se divide en top half y
bottom half
NET_TX_SOFTIRQ y NET_RX_SOFTIRQ
Softirqs

Se planifican y ejecutan en la misma CPU que recibió la
interrupción del dispositivo y, aunque se serializan por CPU,
deben ser funciones reentrantes
Los manejadores de softirqs se ejecutarán cuando el kernel
verifique la existencia de softirqs pendientes. Cuando el tráfico
de red es alto, siempre hay softirqs pendientes
Se suele discutir la escalabilidad de este mecanismo, ya que sólo
hay dos contextos de procesamiento de red por CPU

Los threads del kernel y ksoftirqd

Threads del kernel

no necesitan manejar un contexto en modo usuario
son planificados por el scheduler general, compitiendo con los
procesos del usuario

ksoftirqd

uno asociado a cada procesador de la máquina
verificar si existen softirqs que hayan quedado sin ejecutarse
Bajo cargas intensas de red, el scheduler intercalará
procesamiento de red con el resto de los procesos

La estructrura softnet_data

Desde la versión 2.5 del kernel hay dos formas de proce