13 de diciembre de 2009

libdispatch en el kernel

Resulta curioso que a veces una misma idea florezca con diferentes formas al mismo tiempo sin que entre cada aparición haya aparentemente ninguna relación. Digo esto porque en la próxima versión de Linux va a añadirse un curioso sistema con ideas similares a las del sistema Grand Central Dispatch de OS X pero aplicado exclusivamente al kernel, y no parece que haya ninguna relación entre ambos.

En realidad, la idea -llamada workqueues- existe desde hace muchos años. Conceptualmente se trata de algo similar a GCD -lo que viene siendo un pool de threads-: Un subsistema (por darle un nombre) al que diferentes partes del kernel pueden enviar "trabajos" que se completarán posteriormente. Generalmente, los "trabajos" son creados drivers que tras gestionar una interrupción y recibir los datos pertinentes, envían al subsistema de workqueues un puntero de una función y otro de unos datos para que el resto del trabajo, menos urgente que la gestión de la interrupción, se vaya ejecutando según se pueda, mientras que el driver queda libre para recibir nuevas interrupciones. El kernel ejecuta este trabajo desde los threads del kernel events/N (uno para cada CPU). La novedad en esta versión, y lo que hace que recuerde el sistema de GCD, es una óptima gestión en múltiples CPUs.

Y es que cada driver tiene workqueue al que envían múltiples trabajos, y en el sistema actual todos los trabajos de un mismo workqueue se envian a una sola CPU. Eso implica que si un driver produce una gran cantidad de trabajos, el sistema actual lo ejecutará en una sola CPU, mientras que el resto de CPUs podría estar libre y desaprovechándose. La similitud del nuevo sistema que se incluirá en 2.6.23 con GCD es que es capaz de distribuir los trabajos entre múltiples CPUs según se necesite.

(Aunque, siendo escrupulosos, hay que resaltar que las workqueues no son utilizadas solamente por drivers. Tambien pueden utilizarse por otras partes del kernel, por ejemplo Btrfs para descomprimir los datos; a día de hoy utiliza una cosa rara basada en zlib para que se utilicen todas las CPUs, pero lo previsible es que acabe pasándose a workqueues, ahora que el sistema ya expande el trabajo entre varias CPUs él mismo)

8 comentarios:

  1. Cuando hablas de la versión 2.6.23 del kernel de Linux, me imagino que te refieres a la 2.6.33.

    ResponderEliminar
  2. Anónimo8:35 a. m.

    [...] en zlib para que se utilizen todas las CPUs [...]

    No estaría mal que pasarás un corrector ortográfico antes de publicar.

    ResponderEliminar
  3. Anónimo12:53 p. m.

    Gracias por la explicación. Muy interesante.

    ResponderEliminar
  4. Tienes el link de la fuente original de esta noticia?

    ResponderEliminar
  5. Anónimo3:19 p. m.

    ¿ Añadiría eso soporte también GPU ?

    ResponderEliminar
  6. Anónimo: Gracias por el aviso

    Raine: No hay fuente original, aunque tambien está el artículo de LWN enlazado.

    Anónimo: Las GPUs están soportadas en Linux desde hace tiempo, esto no tiene nada que ver.

    ResponderEliminar
  7. Anónimo3:51 p. m.

    [...] en zlib para que se utilicen[...] es lo correcto, verifica tu corrector ortográfico antes de corregir

    ResponderEliminar
  8. Diego, creo que el "anónimo" anterior se refería a si hay soporte para distribuir ese tipo de procesos del kernel a núcleos de GPUs. Tal como hace la combinación OpenCL + GCD en Mac OS X 10.6

    ResponderEliminar