Implementación de Epoll, parte 4

Este es el último de una serie de cuatro artículos ( Parte 1 , Parte 2 , Parte 3 ) sobre implementación epoll. Aquí hablaremos sobre cómo epolltransfiere eventos desde el espacio del kernel al espacio del usuario, y cómo se implementan los modos de disparo de borde y nivel. Este artículo fue escrito más tarde que los demás. Cuando comencé a trabajar en el primer material, el kernel de Linux estable más reciente era 3.16.1. Y en el momento de escribir este artículo, esta ya es la versión 4.1. Este artículo se basa en el código de esta versión del kernel. Sin embargo, el código no ha cambiado mucho, por lo que los lectores de los artículos anteriores no deberían preocuparse por el hecho de que algo en la implementación haya cambiado mucho.







epoll

Interactuar con el espacio del usuario

En los artículos anteriores, dediqué bastante tiempo a explicar cómo funciona el sistema de manejo de eventos en el kernel. Pero, como sabe, el kernel necesita pasar información sobre eventos a un programa que se ejecuta en el espacio de usuario para que el programa utilice esta información. Esto se hace principalmente con la llamada al sistema epoll_wait (2) .



El código para esta función se puede encontrar en la línea 1961 del archivo fs/eventpoll.c. La función en sí es muy simple. Después de verificaciones bastante normales, simplemente obtiene el puntero eventpolldesde el descriptor de archivo y llama a la siguiente función:

error = ep_poll(ep, events, maxevents, timeout);

Función ep_poll ()

La función se ep_poll()declara en la línea 1585 del mismo archivo. Comienza verificando si el usuario ha establecido un valor timeout. Si es así, la función inicializa la cola de espera y establece el tiempo de espera en el valor especificado por el usuario. Si el usuario no quiere esperar, es decir , timeout = 0, la función pasa inmediatamente al bloque de código con una etiqueta check_events:, que se encarga de copiar el evento.



Si el usuario ha especificado un valor timeout, y no hay eventos que se le puedan informar (su presencia se determina mediante una llamada ep_events_available(ep)), la función se ep_poll()agrega a la cola de espera ep->wq(recuerde lo que hablamos en el tercer artículo de esta serie). Allí mencionamos que ep_poll_callback()en el proceso, activa cualquier proceso que esté esperando en la cola.ep->wq...



Luego, la función entra en espera llamando schedule_hrtimeout_range(). Estas son las circunstancias bajo las cuales un proceso "durmiente" puede "despertar":

1. El tiempo de espera ha expirado.
2. El proceso recibió una señal.
3. Ha surgido un nuevo evento.
4. No pasó nada y el planificador simplemente decidió activar el proceso.

En los escenarios 1, 2 y 3, la función establece los indicadores apropiados y sale del ciclo de espera. En el último caso, la función simplemente vuelve a entrar en modo de espera.



Una vez realizada esta parte del trabajo, ep_poll()continúa ejecutando el código de bloque check_events:.



En este bloque, primero se verifica la presencia de eventos, y luego se realiza la siguiente llamada, donde ocurre lo más interesante.

ep_send_events(ep, events, maxevents)

Función ep_send_events()declarada en la línea 1546. Es, después de la llamada, llama a la función ep_scan_ready_list(), pasando de una devolución de llamada, ep_send_events_proc(). La función ep_scan_ready_list()recorre la lista de descriptores de archivos listos y llama ep_send_events_proc()a cada evento listo que encuentra. A continuación, quedará claro que se necesita un mecanismo que implique el uso de una devolución de llamada para garantizar la seguridad y la reutilización del código.



La función ep_send_events()primero coloca datos de la lista de descriptores de archivo listos para usar de la estructura eventpoolen su variable local. Luego establece el campo de ovflistestructura eventpoolen NULL(y su valor predeterminado es EP_UNACTIVE_PTR).



¿Por qué los autores epollutilizanovflist? ¡Esto se hace para garantizar una alta eficiencia epoll! Puede notar que después de que la lista de descriptores de archivos listos se ha tomado de la estructura eventpool, se ep_scan_ready_list()establece ovflisten NULL. Esto da como resultado que ep_poll_callback()no intente adjuntar el evento que se está pasando al espacio de usuario ep->rdllist, lo que puede generar grandes problemas. Al usar la ovflistfunción, no es ep_scan_ready_list()necesario mantener un candado ep->lockmientras se copian eventos en el espacio del usuario. Como resultado, se mejora el rendimiento general de la solución.



Después de eso, ep_send_events_proc()omitirá la lista de descriptores de archivos listos que tiene y volverá a llamar a sus métodos.poll()para asegurarse de que el evento realmente sucedió. ¿Por qué epollvolver a consultar los eventos aquí? Esto se hace para asegurarse de que el evento (o eventos) registrado por el usuario todavía esté disponible. Considere una situación en la que se agregó un descriptor de archivo a la lista de descriptores listos para archivo por evento EPOLLOUTmientras el programa de usuario está escribiendo en ese descriptor. Una vez que el programa termina de escribir, es posible que ya no se pueda escribir en el descriptor de archivo. Epollnecesita manejar situaciones como esta correctamente. De lo contrario, el usuario recibirá EPOLLOUTen el momento en que se bloquee la operación de escritura.



Aquí, sin embargo, vale la pena mencionar un detalle. Funciónep_send_events_proc()hace todo lo posible para garantizar que los programas de espacio de usuario reciban notificaciones de eventos precisas. Es posible, aunque poco probable, que la disponibilidad de un conjunto de eventos cambie después del ep_send_events_proc()desencadenante poll(). En este caso, un programa de espacio de usuario puede recibir una notificación de un evento que ya no existe. Es por eso que se considera correcto usar siempre enchufes sin bloqueo cuando se aplica epoll. Esto evita que su aplicación se bloquee inesperadamente.



Después de verificar la máscara del evento, ep_send_events_proc()simplemente copia la estructura del evento en el búfer proporcionado por el programa de espacio de usuario.

Activado por flanco y activado por nivel

Ahora finalmente podemos discutir la diferencia entre Edge Triggering (ET) y Level Triggering (LT) en términos de su implementación.

else if (!(epi->event.events & EPOLLET)) {
    list_add_tail(&epi->rdllink, &ep->rdllist);
}

¡Es muy fácil! La función ep_send_events_proc()vuelve a agregar el evento a la lista de descriptores de archivos listos. Como resultado, en la próxima llamada, se ep_poll()volverá a comprobar el mismo descriptor de archivo. Dado que ep_send_events_proc()siempre llama a un archivo poll()antes de devolverlo a la aplicación de espacio de usuario, esto aumenta ligeramente la sobrecarga del sistema (en comparación con ET) si el descriptor de archivo ya no está disponible. Pero el objetivo de todo esto es, como se mencionó anteriormente, no informar eventos que ya no están disponibles.



Una vez que ep_send_events_proc()termina de copiar eventos, la función devuelve el número de eventos copiados, manteniendo la aplicación de espacio de usuario actualizada.



Cuando la función ha ep_send_events_proc()terminado, las funcionesep_scan_ready_list()Necesito limpiar un poco. Primero, regresa a la lista de descriptores de archivos listos los eventos que la función dejó sin procesar ep_send_events_proc(). Esto puede suceder si el número de eventos disponibles excede el tamaño del búfer proporcionado por el programa de usuario. También ep_send_events_proc()adjunta rápidamente todos los eventos ovflist, si los hay, a la lista de descriptores de archivos listos. Además, se ovflistregistra de nuevo EP_UNACTIVE_PTR. Como resultado, los nuevos eventos se adjuntarán a la lista de espera principal ( rdllist). La función sale activando cualquier otro proceso "durmiente" en caso de que haya otros eventos disponibles.

Salir

Con esto concluye el cuarto y último artículo de la serie de implementación epoll. Mientras escribo estos artículos, me ha impresionado el tremendo trabajo mental que han realizado los autores del código del kernel de Linux para lograr la máxima eficiencia y escalabilidad. Y agradezco a todos los autores de código Linux por compartir su conocimiento con todos los que lo necesitan al compartir los resultados de su trabajo.



¿Qué opina del software de código abierto?