[PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst

[PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst

[Sergio González Collado]

Translate Documentation/scheduler/sched-design-CFS.rst into Spanish

Signed-off-by: Sergio González Collado <sergio.collado@gmail.com>
---
 Documentation/scheduler/sched-design-CFS.rst  |   2 +
 Documentation/translations/sp_SP/index.rst    |   1 +
 .../translations/sp_SP/scheduler/index.rst    |   8 +
 .../sp_SP/scheduler/sched-design-CFS.rst      | 275 ++++++++++++++++++
 4 files changed, 286 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/scheduler/index.rst
 create mode 100644 Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst

diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst
index e030876fbd68..bc1e507269c6 100644
--- a/Documentation/scheduler/sched-design-CFS.rst
+++ b/Documentation/scheduler/sched-design-CFS.rst
@@ -1,3 +1,5 @@
+.. _sched_design_CFS:
+
 =============
 CFS Scheduler
 =============
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
index 274ef4ad96b9..aae7018b0d1a 100644
--- a/Documentation/translations/sp_SP/index.rst
+++ b/Documentation/translations/sp_SP/index.rst
@@ -78,3 +78,4 @@ Traducciones al español
 
    process/index
    wrappers/memory-barriers
+   scheduler/index
diff --git a/Documentation/translations/sp_SP/scheduler/index.rst b/Documentation/translations/sp_SP/scheduler/index.rst
new file mode 100644
index 000000000000..768488d6f001
--- /dev/null
+++ b/Documentation/translations/sp_SP/scheduler/index.rst
@@ -0,0 +1,8 @@
+.. include:: ../disclaimer-sp.rst
+
+.. _sp_scheduler_index:
+
+.. toctree::
+    :maxdepth: 1
+
+    sched-design-CFS
diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
new file mode 100644
index 000000000000..43e29297d7fa
--- /dev/null
+++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
@@ -0,0 +1,275 @@
+.. include:: ../disclaimer-sp.rst
+
+:Original: :ref:`Documentation/scheduler/sched-design-CFS.rst <sched_design_CFS>`
+:Translator: Sergio González Collado <sergio.collado@gmail.com>
+
+.. _sp_sched_desing_CFS:
+
+====================
+Gestor de tareas CFS
+====================
+
+1.  VISIÓN GENERAL
+==================
+
+CFS viene de las siglas en inglés de "Gestor te tareas totalmente justo"
+("Completely Fair Scheduler"), y es el nuevo gestor de tareas de escritorio
+implementado por Ingo Molnar e integrado en Linux 2.6.23. Es el sustituto de
+el previo gestor de tareas SCHED_OTHER.
+
+El 80% del diseño de CFS puede ser resumido en una única frase: CFS
+básicamente modela una "CPU ideal, precisa y multi-tarea" sobre hardware
+real.
+
+"una CPU multitarea ideal" es una CPU (inexistente :-)) que tiene un 100%
+de potencia y que puede ejecutar cualquier tarea exactamente a la misma
+velocidad, en paralelo, y cada una a 1/n velocidad. Por ejemplo, si hay dos
+tareas ejecutándose, entonces cada una usa un 50% de la potencia --- es decir,
+como si se ejecutaran en paralelo.
+
+En un hardware real, se puede ejecutar una única tarea a la vez, así que
+se ha usado el concepto de "tiempo de ejecución virtual". El tiempo
+de ejecución virtual de una tarea, específica cuando la siguiente porción
+de ejecución podría empezar en la CPU ideal multi-tarea descrita anteriormente.
+En la práctica, el tiempo de ejecución virtual de una tarea es el
+tiempo de ejecución real normalizado con respecto al número total de
+tareas ejecutándose.
+
+
+2.  UNOS CUANTOS DETALLES DE IMPLEMENTACIÓN
+===========================================
+
+En CFS, el tiempo de ejecución virtual se expresa y se monitoriza por
+cada tarea, en su valor de p->se.vruntime (en unidades de nanosegundos).
+De este modo, es posible temporizar con precisión y medir el "tiempo
+de CPU esperado" que una tarea debería tener.
+
+Un pequeño detalle: en hardware "ideal", en cualquier momento todas las
+tareas pueden tener el mismo valor de p->se.vruntime --- i.e., tareas
+se podrían ejecutar simultáneamente y ninguna tarea podría escaparse del
+"balance" de la partición "ideal" del tiempo compartido de la CPU.
+
+La lógica de elección del tareas de CFS se basa en el valor de p->se.vruntime
+y por tanto es muy sencilla: siempre intenta ejecutar la tarea con el valor
+p->se.vruntime más pequeño (i.e., la tarea que se ha ejecutado menos hasta el
+momento). CFS siempre intenta dividir el espacio de tiempo entre tareas
+en ejecución tan próximo a la "ejecución multitarea ideal del hardware" como
+sea posible.
+
+El resto del diseño de CFS simplemente se escapa de este simple concepto,
+con unos cuantos añadidos como los niveles "nice" ("nice" significa "amable"
+en inglés), multi-tarea y varias variantes del algoritmo para identificar
+tareas "durmiendo".
+
+
+3.  EL ÁRBOL ROJO-NEGRO
+=======================
+
+El diseño de CFS es bastante radical: no utiliza las antiguas estructuras
+de datos para las colas de ejecución (en inglés "runqueues"), pero usa una
+estructura de árbol rojo-negro (en inglés "red-black tree") ordenado cronológicamente
+para construir un línea de ejecución en el futuro, y por eso no tiene ningún
+artificio de "cambio de tareas" (algo que previamente era usado por el gestor
+anterior y RSDL/SD).
+
+CFS también mantiene el valor de rq->cfs.min_vruntime, el cual crece
+monotónicamente siguiendo el valor más pequeño de vruntime de entre todas
+las tareas en la cola de ejecución. La cantidad total de trabajo realizado
+por el sistema es monitorizado usado min_vruntime; este valor es usado
+para situar las nuevas tareas en la parte izquierda del árbol tanto
+como sea posible.
+
+El valor total de tareas ejecutándose en la cola de ejecución es
+contabilizado mediante el valor rq->cfs.load, el cual es la suma de los
+de esas tareas que están en la cola de ejecución.
+
+CFS mantiene un árbol rojo-negro cronológiamente ordenado, donde todas las
+tareas que pueden ser ejecutadas están ordenadas por su valor de
+p->se.vruntime. CFS selecciona la tarea más hacia la izquierda de este
+árbol y la mantiene. Según el sistema continúa, las tareas ejecutadas
+se ponen en este árbol más y más hacia la derecha --- lentamente pero
+de forma continuada dando una oportunidad a cada tarea de ser la que
+está "la más hacia la izquierda" y por tanto obtener la CPU una cantidad
+determinista de tiempo.
+
+Resumiendo, CFS funciona así: ejecuta una tarea un tiempo, y cuando la
+tarea se gestiona (o sucede un tic del gestor de tareas) se considera
+que el tiempo de uso de la CPU se ha completado, y se añade a
+p->se.vruntime. Una vez p->se.vruntime ha aumentado lo suficiente como
+para que otra tarea sea "la tarea más hacia la izquierda" del árbol
+rojo-negro ordenado cronológicamente esta mantienen (más una cierta pequeña
+cantidad de distancia relativa a la tarea más hacia la izquierda para
+que no se sobre-reserven tareas y perjudique a la cache), entonces la
+nueva tarea "que está a la izquierda del todo", es la que se elige
+para que se ejecute, y la tarea en ejecución es interrumpida.
+
+4.  ALGUNAS CARACTERÍSTICAS DE CFS
+==================================
+
+CFS usa una granularidad de nanosegundos y no depende de ningún
+jiffie o detalles como HZ. De este modo el gestor de tareas CFS no tiene
+noción de "ventanas de tiempo" de la forma en que tenía el gestor de
+tareas previo, y tampoco tiene heurísticos. Únicamente hay un parámetro
+central ajustable (se ha de cambiar en CONFIG_SCHED_DEBUG):
+
+   /sys/kernel/debug/sched/base_slice_ns
+
+El cual puede ser usado para afinar desde el gestor de tareas del "escritorio"
+(i.e., bajas latencias) hacia cargas de "servidor" (i.e., bueno con
+procesamientos). Su valor por defecto es adecuado para tareas de escritorio.
+SCHED_BATCH también es gestionado por el gestor de tareas CFS.
+
+Debido a su diseño, el gestor de tareas CFS no es proclive a ninguno de los
+ataques que existen a día de hoy contra los heurísticos del gestor de tareas:
+fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c todos trabajan
+correctamente y no tienen impacto en la interacción y se comportan de la forma
+esperada.
+
+El gestor de tareas CFS tiene una gestión mucho más firme de los niveles
+"nice" y SCHED_BATCH que los previos gestores de tareas: ambos tipos de
+tareas están aisladas de forma más eficiente.
+
+El balanceo de tareas SMP ha sido rehecho/mejorado: el avance por las
+colas de ejecución de tareas ha desaparecido del código de balanceo de
+carga, y ahora se usan iteradores en la gestión de módulos. El balanceo
+del código ha sido simplificado como resultado esto.
+
+5.  Políticas de gestión de tareas
+==================================
+
+CFS implementa tres políticas de gestión de tareas:
+
+  - SCHED_NORMAL (tradicionalmente llamada SCHED_OTHER): Gestión de
+    tareas que se usan para tareas normales.
+
+  - SCHED_BATCH: No interrumpe tareas tan amenudo como las tareas
+    normales harían, por eso permite a las tareas ejecutarse durante
+    ventanas de tiempo mayores y hace un uso más efectivo de las
+    caches pero al coste de la interactividad. Esto es adecuado
+    para trabajos de procesado de datos.
+
+  - SCHED_IDLE: Esta política es más débil incluso que nice 19, pero
+    no es un gestor "idle" para evitar caer en el problema de la
+    inversión de prioridades que causaría un bloqueo de la máquina
+    (deadlock).
+
+SCHED_FIFO/_RR se implementan en sched/rt.c y son específicos de
+POSIX.
+
+El comando chrt de util-linux-ng 2.13.1.1. puede asignar cualquiera de
+estas políticas excepto SCHED_IDLE.
+
+
+6.  CLASES DE GESTIÓN
+=====================
+
+El nuevo gestor de tareas CFS ha sido diseñado de tal modo para incluir
+"clases de gestión", una jerarquía ampliable de módulos que pueden tener
+distintas políticas de gestión de tareas. Estos módulos encapsulan los
+detalles de las politicas de gestion y son manejadas por el núcleo del
+gestor de tareas sin que este tenga que presuponer mucho sobre estas clases.
+
+sched/fair.c implementa el gestor de tareas CFS descrito arriba.
+
+sched/rt.c implementa la semántica de SCHED_FIFO y SCHED_RR, de una forma
+más sencilla que el gestor de tareas anterior. Usa 100 colas de ejecución
+(por todos los 100 niveles de prioridad RT, en vez de las 140 que necesitaba
+el gestor de tareas anterior) y no necesita las listas de expiración.
+
+Las clases de gestión de tareas son implementadas por medio de la estructura
+sched_class, la cual tiene llamadas a las funciones que deben de llamarse
+cuando quiera que ocurra un evento interesante.
+
+Esta es la lista parcial de llamadas:
+
+ - enqueue_task(...)
+
+   Llamada cuando una tarea entra en el estado de lista para ejecución.
+   Pone la entidad a ser gestionada (la tarea) en el árbol rojo-negro
+   e incrementa la variable nr_running.
+
+ - dequeue_task(...)
+
+   Cuando una tarea deja de ser ejecutable, esta función se llama para
+   mantener a la entidad gestionada fuera del árbol rojo-negor. Esto
+   decrementa la variable nr_running.
+
+ - yield_task(...)
+
+   Esta función es básicamente desencolar, seguido por encolar, a menos que
+   sysctl compat_yield esté activado; en ese caso, sitúa la entidad a gestionar
+   en la parte más hacia la derecha del árbol rojo-negro.
+
+ - check_preempt_curr(...)
+
+   Esta función comprueba si una tarea que ha entrado en el estado de
+   poder ser ejecutada, podría reemplazar a la tarea que actualmente
+   se esté ejecutando.
+
+ - pick_next_task(...)
+
+   Esta función elige la tarea más apropiada para ser ejecutada a continuación.
+
+ - set_curr_task(...)
+
+   Esta función se llama cuando una tarea cambia su clase de gestión o
+   cambia su grupo de tareas.
+
+ - task_tick(...)
+
+   Esta función es llamada la mayoría de las veces desde la función de tiempo
+   tick; esto puede llevar a un cambio de procesos. Esto dirige el reemplazo
+   de las tareas.
+
+
+7.  EXTENSIONES DE GRUPOS PARA CFS
+==================================
+
+Normalmente, el gestor de tareas gestiona tareas individuales e intenta
+proporcionar una cantidad justa de CPU a cada tarea. Algunas veces, puede
+ser deseable agrupar las tareas y proporcionarles una cantidad justa
+de tiempo de CPU a cada una de las tareas de ese grupo. Por ejemplo,
+podría ser deseable que primero se proporcione una cantidad justa de
+tiempo de CPU a cada usuario del sistema y después a cada tarea
+que pertenezca a un usuario.
+
+CONFIG_CGROUP_SCHED destaca en conseguir exactamente eso. Permite a las
+tareas ser agrupadas y divide el tiempo de CPU de forma just entre esos
+grupos.
+
+CONFIG_RT_GROUP_SCHED permite agrupar tareas de tiempo real (i.e.,
+SCHED_FIFO y SCHED_RR).
+
+CONFIG_FAIR_GROUP_SCHED permite agrupar tareas de CFS (i.e., SCHED_NORMAL y
+SCHED_BATCH).
+
+Estas opciones necesitan CONFIG_CGROUPS para ser definidas, y permitir
+al administrador crear grupos arbitrarios de tareas, usando el pseudo
+sistema de archivos "cgroup". Vease la documentación para más información
+sobre este sistema de archivos: Documentation/admin-guide/cgroup-v1/cgroups.rst
+
+Cuando CONFIG_FAIR_GROUP_SCHED es definido, un archivo
+"cpu.shares" es creado por cada grupo creado usado en el pseudo
+sistema de archivos. Véanse por ejemplo los pasos a continuación
+para crear grupos de tareas y modificar cuanto comparten de la CPU
+usando el pseudo sistema de archivos "cgroup" ::
+
+	# mount -t tmpfs cgroup_root /sys/fs/cgroup
+	# mkdir /sys/fs/cgroup/cpu
+	# mount -t cgroup -ocpu none /sys/fs/cgroup/cpu
+	# cd /sys/fs/cgroup/cpu
+
+	# mkdir multimedia	# crear un grupo de tareas "multimedia"
+	# mkdir browser 	# crear un grupo de tareas "browser"
+
+	# #Configurar el grupo multimedia para tener el doble de tiempo de CPU
+	# #que el grupo browser
+
+	# echo 2048 > multimedia/cpu.shares
+	# echo 1024 > browser/cpu.shares
+
+	# firefox &	# Lanzar firefox y moverlo al grupo "browser"
+	# echo <firefox_pid> > browser/tasks
+
+	# #Lanzar gmplayer (o su programa favorito de reproducción de películas)
+	# echo <movie_player_pid> > multimedia/tasks
-- 
2.39.2

Re: [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst

[Carlos Bilbao]

Hello,

On 7/6/24 08:22, Sergio González Collado wrote:
> Translate Documentation/scheduler/sched-design-CFS.rst into Spanish
>
> Signed-off-by: Sergio González Collado <sergio.collado@gmail.com>
> ---
>  Documentation/scheduler/sched-design-CFS.rst  |   2 +
>  Documentation/translations/sp_SP/index.rst    |   1 +
>  .../translations/sp_SP/scheduler/index.rst    |   8 +
>  .../sp_SP/scheduler/sched-design-CFS.rst      | 275 ++++++++++++++++++
>  4 files changed, 286 insertions(+)
>  create mode 100644 Documentation/translations/sp_SP/scheduler/index.rst
>  create mode 100644 Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
>
> diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst
> index e030876fbd68..bc1e507269c6 100644
> --- a/Documentation/scheduler/sched-design-CFS.rst
> +++ b/Documentation/scheduler/sched-design-CFS.rst
> @@ -1,3 +1,5 @@
> +.. _sched_design_CFS:
> +
>  =============
>  CFS Scheduler
>  =============
> diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
> index 274ef4ad96b9..aae7018b0d1a 100644
> --- a/Documentation/translations/sp_SP/index.rst
> +++ b/Documentation/translations/sp_SP/index.rst
> @@ -78,3 +78,4 @@ Traducciones al español
>  
>     process/index
>     wrappers/memory-barriers
> +   scheduler/index
> diff --git a/Documentation/translations/sp_SP/scheduler/index.rst b/Documentation/translations/sp_SP/scheduler/index.rst
> new file mode 100644
> index 000000000000..768488d6f001
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/scheduler/index.rst
> @@ -0,0 +1,8 @@
> +.. include:: ../disclaimer-sp.rst
> +
> +.. _sp_scheduler_index:
> +
> +.. toctree::
> +    :maxdepth: 1
> +
> +    sched-design-CFS
> diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
> new file mode 100644
> index 000000000000..43e29297d7fa
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
> @@ -0,0 +1,275 @@
> +.. include:: ../disclaimer-sp.rst
> +
> +:Original: :ref:`Documentation/scheduler/sched-design-CFS.rst <sched_design_CFS>`
> +:Translator: Sergio González Collado <sergio.collado@gmail.com>
> +
> +.. _sp_sched_desing_CFS:
> +
> +====================
> +Gestor de tareas CFS
> +====================
> +
> +1.  VISIÓN GENERAL
> +==================
> +
> +CFS viene de las siglas en inglés de "Gestor te tareas totalmente justo"


Change 'te' to 'de'. For the rest of the review, I'll say instead:
's/old/new', in this case, s/te/de.


> +("Completely Fair Scheduler"), y es el nuevo gestor de tareas de escritorio
> +implementado por Ingo Molnar e integrado en Linux 2.6.23. Es el sustituto de
> +el previo gestor de tareas SCHED_OTHER.


Although I usually don't do this, considering that CFS is no longer the
most recent scheduler, let's add a note here:

Nota: El planificador EEVDF fue incorporado más recientemente al kernel.


> +
> +El 80% del diseño de CFS puede ser resumido en una única frase: CFS
> +básicamente modela una "CPU ideal, precisa y multi-tarea" sobre hardware
> +real.
> +
> +"una CPU multitarea ideal" es una CPU (inexistente :-)) que tiene un 100%
> +de potencia y que puede ejecutar cualquier tarea exactamente a la misma
> +velocidad, en paralelo, y cada una a 1/n velocidad. Por ejemplo, si hay dos
> +tareas ejecutándose, entonces cada una usa un 50% de la potencia --- es decir,
> +como si se ejecutaran en paralelo.
> +
> +En un hardware real, se puede ejecutar una única tarea a la vez, así que


s/En un hardware/En hardware


> +se ha usado el concepto de "tiempo de ejecución virtual". El tiempo
> +de ejecución virtual de una tarea, específica cuando la siguiente porción


s/tarea,/tarea


> +de ejecución podría empezar en la CPU ideal multi-tarea descrita anteriormente.
> +En la práctica, el tiempo de ejecución virtual de una tarea es el
> +tiempo de ejecución real normalizado con respecto al número total de
> +tareas ejecutándose.
> +
> +
> +2.  UNOS CUANTOS DETALLES DE IMPLEMENTACIÓN
> +===========================================
> +
> +En CFS, el tiempo de ejecución virtual se expresa y se monitoriza por
> +cada tarea, en su valor de p->se.vruntime (en unidades de nanosegundos).
> +De este modo, es posible temporizar con precisión y medir el "tiempo
> +de CPU esperado" que una tarea debería tener.
> +
> +Un pequeño detalle: en hardware "ideal", en cualquier momento todas las
> +tareas pueden tener el mismo valor de p->se.vruntime --- i.e., tareas
> +se podrían ejecutar simultáneamente y ninguna tarea podría escaparse del
> +"balance" de la partición "ideal" del tiempo compartido de la CPU.
> +
> +La lógica de elección del tareas de CFS se basa en el valor de p->se.vruntime
> +y por tanto es muy sencilla: siempre intenta ejecutar la tarea con el valor
> +p->se.vruntime más pequeño (i.e., la tarea que se ha ejecutado menos hasta el
> +momento). CFS siempre intenta dividir el espacio de tiempo entre tareas
> +en ejecución tan próximo a la "ejecución multitarea ideal del hardware" como
> +sea posible.
> +
> +El resto del diseño de CFS simplemente se escapa de este simple concepto,
> +con unos cuantos añadidos como los niveles "nice" ("nice" significa "amable"
> +en inglés), multi-tarea y varias variantes del algoritmo para identificar
> +tareas "durmiendo".
> +
> +
> +3.  EL ÁRBOL ROJO-NEGRO
> +=======================
> +
> +El diseño de CFS es bastante radical: no utiliza las antiguas estructuras
> +de datos para las colas de ejecución (en inglés "runqueues"), pero usa una
> +estructura de árbol rojo-negro (en inglés "red-black tree") ordenado cronológicamente
> +para construir un línea de ejecución en el futuro, y por eso no tiene ningún
> +artificio de "cambio de tareas" (algo que previamente era usado por el gestor
> +anterior y RSDL/SD).
> +
> +CFS también mantiene el valor de rq->cfs.min_vruntime, el cual crece
> +monotónicamente siguiendo el valor más pequeño de vruntime de entre todas
> +las tareas en la cola de ejecución. La cantidad total de trabajo realizado
> +por el sistema es monitorizado usado min_vruntime; este valor es usado
> +para situar las nuevas tareas en la parte izquierda del árbol tanto
> +como sea posible.
> +
> +El valor total de tareas ejecutándose en la cola de ejecución es
> +contabilizado mediante el valor rq->cfs.load, el cual es la suma de los
> +de esas tareas que están en la cola de ejecución.
> +
> +CFS mantiene un árbol rojo-negro cronológiamente ordenado, donde todas las


s/cronológiamente/cronológicamente


> +tareas que pueden ser ejecutadas están ordenadas por su valor de
> +p->se.vruntime. CFS selecciona la tarea más hacia la izquierda de este
> +árbol y la mantiene. Según el sistema continúa, las tareas ejecutadas
> +se ponen en este árbol más y más hacia la derecha --- lentamente pero
> +de forma continuada dando una oportunidad a cada tarea de ser la que
> +está "la más hacia la izquierda" y por tanto obtener la CPU una cantidad
> +determinista de tiempo.
> +
> +Resumiendo, CFS funciona así: ejecuta una tarea un tiempo, y cuando la
> +tarea se gestiona (o sucede un tic del gestor de tareas) se considera
> +que el tiempo de uso de la CPU se ha completado, y se añade a
> +p->se.vruntime. Una vez p->se.vruntime ha aumentado lo suficiente como
> +para que otra tarea sea "la tarea más hacia la izquierda" del árbol
> +rojo-negro ordenado cronológicamente esta mantienen (más una cierta pequeña
> +cantidad de distancia relativa a la tarea más hacia la izquierda para
> +que no se sobre-reserven tareas y perjudique a la cache), entonces la
> +nueva tarea "que está a la izquierda del todo", es la que se elige
> +para que se ejecute, y la tarea en ejecución es interrumpida.
> +
> +4.  ALGUNAS CARACTERÍSTICAS DE CFS
> +==================================
> +
> +CFS usa una granularidad de nanosegundos y no depende de ningún
> +jiffie o detalles como HZ. De este modo el gestor de tareas CFS no tiene


s/modo/modo,


> +noción de "ventanas de tiempo" de la forma en que tenía el gestor de
> +tareas previo, y tampoco tiene heurísticos. Únicamente hay un parámetro
> +central ajustable (se ha de cambiar en CONFIG_SCHED_DEBUG):
> +
> +   /sys/kernel/debug/sched/base_slice_ns
> +
> +El cual puede ser usado para afinar desde el gestor de tareas del "escritorio"
> +(i.e., bajas latencias) hacia cargas de "servidor" (i.e., bueno con
> +procesamientos). Su valor por defecto es adecuado para tareas de escritorio.
> +SCHED_BATCH también es gestionado por el gestor de tareas CFS.
> +
> +Debido a su diseño, el gestor de tareas CFS no es proclive a ninguno de los
> +ataques que existen a día de hoy contra los heurísticos del gestor de tareas:
> +fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c todos trabajan
> +correctamente y no tienen impacto en la interacción y se comportan de la forma
> +esperada.
> +
> +El gestor de tareas CFS tiene una gestión mucho más firme de los niveles
> +"nice" y SCHED_BATCH que los previos gestores de tareas: ambos tipos de
> +tareas están aisladas de forma más eficiente.
> +
> +El balanceo de tareas SMP ha sido rehecho/mejorado: el avance por las
> +colas de ejecución de tareas ha desaparecido del código de balanceo de
> +carga, y ahora se usan iteradores en la gestión de módulos. El balanceo
> +del código ha sido simplificado como resultado esto.
> +
> +5.  Políticas de gestión de tareas
> +==================================
> +
> +CFS implementa tres políticas de gestión de tareas:
> +
> +  - SCHED_NORMAL (tradicionalmente llamada SCHED_OTHER): Gestión de
> +    tareas que se usan para tareas normales.
> +
> +  - SCHED_BATCH: No interrumpe tareas tan amenudo como las tareas


s/amenudo/a menudo


> +    normales harían, por eso permite a las tareas ejecutarse durante
> +    ventanas de tiempo mayores y hace un uso más efectivo de las
> +    caches pero al coste de la interactividad. Esto es adecuado
> +    para trabajos de procesado de datos.
> +
> +  - SCHED_IDLE: Esta política es más débil incluso que nice 19, pero
> +    no es un gestor "idle" para evitar caer en el problema de la
> +    inversión de prioridades que causaría un bloqueo de la máquina
> +    (deadlock).
> +
> +SCHED_FIFO/_RR se implementan en sched/rt.c y son específicos de
> +POSIX.
> +
> +El comando chrt de util-linux-ng 2.13.1.1. puede asignar cualquiera de
> +estas políticas excepto SCHED_IDLE.
> +
> +
> +6.  CLASES DE GESTIÓN
> +=====================
> +
> +El nuevo gestor de tareas CFS ha sido diseñado de tal modo para incluir
> +"clases de gestión", una jerarquía ampliable de módulos que pueden tener
> +distintas políticas de gestión de tareas. Estos módulos encapsulan los
> +detalles de las politicas de gestion y son manejadas por el núcleo del


s/gestion/gestión


> +gestor de tareas sin que este tenga que presuponer mucho sobre estas clases.
> +
> +sched/fair.c implementa el gestor de tareas CFS descrito arriba.


s/arriba/antes


> +
> +sched/rt.c implementa la semántica de SCHED_FIFO y SCHED_RR, de una forma
> +más sencilla que el gestor de tareas anterior. Usa 100 colas de ejecución
> +(por todos los 100 niveles de prioridad RT, en vez de las 140 que necesitaba
> +el gestor de tareas anterior) y no necesita las listas de expiración.
> +
> +Las clases de gestión de tareas son implementadas por medio de la estructura
> +sched_class, la cual tiene llamadas a las funciones que deben de llamarse
> +cuando quiera que ocurra un evento interesante.
> +
> +Esta es la lista parcial de llamadas:
> +
> + - enqueue_task(...)
> +
> +   Llamada cuando una tarea entra en el estado de lista para ejecución.
> +   Pone la entidad a ser gestionada (la tarea) en el árbol rojo-negro
> +   e incrementa la variable nr_running.
> +
> + - dequeue_task(...)
> +
> +   Cuando una tarea deja de ser ejecutable, esta función se llama para
> +   mantener a la entidad gestionada fuera del árbol rojo-negor. Esto
> +   decrementa la variable nr_running.
> +
> + - yield_task(...)
> +
> +   Esta función es básicamente desencolar, seguido por encolar, a menos que
> +   sysctl compat_yield esté activado; en ese caso, sitúa la entidad a gestionar
> +   en la parte más hacia la derecha del árbol rojo-negro.
> +
> + - check_preempt_curr(...)
> +
> +   Esta función comprueba si una tarea que ha entrado en el estado de
> +   poder ser ejecutada, podría reemplazar a la tarea que actualmente
> +   se esté ejecutando.
> +
> + - pick_next_task(...)
> +
> +   Esta función elige la tarea más apropiada para ser ejecutada a continuación.
> +
> + - set_curr_task(...)
> +
> +   Esta función se llama cuando una tarea cambia su clase de gestión o
> +   cambia su grupo de tareas.
> +
> + - task_tick(...)
> +
> +   Esta función es llamada la mayoría de las veces desde la función de tiempo
> +   tick; esto puede llevar a un cambio de procesos. Esto dirige el reemplazo
> +   de las tareas.
> +
> +
> +7.  EXTENSIONES DE GRUPOS PARA CFS
> +==================================
> +
> +Normalmente, el gestor de tareas gestiona tareas individuales e intenta
> +proporcionar una cantidad justa de CPU a cada tarea. Algunas veces, puede
> +ser deseable agrupar las tareas y proporcionarles una cantidad justa
> +de tiempo de CPU a cada una de las tareas de ese grupo. Por ejemplo,
> +podría ser deseable que primero se proporcione una cantidad justa de
> +tiempo de CPU a cada usuario del sistema y después a cada tarea
> +que pertenezca a un usuario.
> +
> +CONFIG_CGROUP_SCHED destaca en conseguir exactamente eso. Permite a las
> +tareas ser agrupadas y divide el tiempo de CPU de forma just entre esos
> +grupos.
> +
> +CONFIG_RT_GROUP_SCHED permite agrupar tareas de tiempo real (i.e.,
> +SCHED_FIFO y SCHED_RR).
> +
> +CONFIG_FAIR_GROUP_SCHED permite agrupar tareas de CFS (i.e., SCHED_NORMAL y
> +SCHED_BATCH).
> +
> +Estas opciones necesitan CONFIG_CGROUPS para ser definidas, y permitir
> +al administrador crear grupos arbitrarios de tareas, usando el pseudo
> +sistema de archivos "cgroup". Vease la documentación para más información
> +sobre este sistema de archivos: Documentation/admin-guide/cgroup-v1/cgroups.rst
> +
> +Cuando CONFIG_FAIR_GROUP_SCHED es definido, un archivo
> +"cpu.shares" es creado por cada grupo creado usado en el pseudo
> +sistema de archivos. Véanse por ejemplo los pasos a continuación
> +para crear grupos de tareas y modificar cuanto comparten de la CPU
> +usando el pseudo sistema de archivos "cgroup" ::
> +
> +	# mount -t tmpfs cgroup_root /sys/fs/cgroup
> +	# mkdir /sys/fs/cgroup/cpu
> +	# mount -t cgroup -ocpu none /sys/fs/cgroup/cpu
> +	# cd /sys/fs/cgroup/cpu
> +
> +	# mkdir multimedia	# crear un grupo de tareas "multimedia"
> +	# mkdir browser 	# crear un grupo de tareas "browser"
> +
> +	# #Configurar el grupo multimedia para tener el doble de tiempo de CPU
> +	# #que el grupo browser
> +
> +	# echo 2048 > multimedia/cpu.shares
> +	# echo 1024 > browser/cpu.shares
> +
> +	# firefox &	# Lanzar firefox y moverlo al grupo "browser"
> +	# echo <firefox_pid> > browser/tasks
> +
> +	# #Lanzar gmplayer (o su programa favorito de reproducción de películas)
> +	# echo <movie_player_pid> > multimedia/tasks


Sergio, thank you for contributing to the documentation in Spanish. This is
excellent work! Please, send a v2 with these minor changes, and you can
add:
Reviewed-by: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
Thanks,
Carlos

Re: [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst

[Sergio González Collado]

Thanks for the review!

Maybe we could consider updating the original documentation with the
EEVDF scheduler info.

Best regards,
 Sergio.

On Sat, 6 Jul 2024 at 21:00, Carlos Bilbao
<carlos.bilbao.osdev@gmail.com> wrote:
>
> Hello,
>
> On 7/6/24 08:22, Sergio González Collado wrote:
> > Translate Documentation/scheduler/sched-design-CFS.rst into Spanish
> >
> > Signed-off-by: Sergio González Collado <sergio.collado@gmail.com>
> > ---
> >  Documentation/scheduler/sched-design-CFS.rst  |   2 +
> >  Documentation/translations/sp_SP/index.rst    |   1 +
> >  .../translations/sp_SP/scheduler/index.rst    |   8 +
> >  .../sp_SP/scheduler/sched-design-CFS.rst      | 275 ++++++++++++++++++
> >  4 files changed, 286 insertions(+)
> >  create mode 100644 Documentation/translations/sp_SP/scheduler/index.rst
> >  create mode 100644 Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
> >
> > diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst
> > index e030876fbd68..bc1e507269c6 100644
> > --- a/Documentation/scheduler/sched-design-CFS.rst
> > +++ b/Documentation/scheduler/sched-design-CFS.rst
> > @@ -1,3 +1,5 @@
> > +.. _sched_design_CFS:
> > +
> >  =============
> >  CFS Scheduler
> >  =============
> > diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
> > index 274ef4ad96b9..aae7018b0d1a 100644
> > --- a/Documentation/translations/sp_SP/index.rst
> > +++ b/Documentation/translations/sp_SP/index.rst
> > @@ -78,3 +78,4 @@ Traducciones al español
> >
> >     process/index
> >     wrappers/memory-barriers
> > +   scheduler/index
> > diff --git a/Documentation/translations/sp_SP/scheduler/index.rst b/Documentation/translations/sp_SP/scheduler/index.rst
> > new file mode 100644
> > index 000000000000..768488d6f001
> > --- /dev/null
> > +++ b/Documentation/translations/sp_SP/scheduler/index.rst
> > @@ -0,0 +1,8 @@
> > +.. include:: ../disclaimer-sp.rst
> > +
> > +.. _sp_scheduler_index:
> > +
> > +.. toctree::
> > +    :maxdepth: 1
> > +
> > +    sched-design-CFS
> > diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
> > new file mode 100644
> > index 000000000000..43e29297d7fa
> > --- /dev/null
> > +++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
> > @@ -0,0 +1,275 @@
> > +.. include:: ../disclaimer-sp.rst
> > +
> > +:Original: :ref:`Documentation/scheduler/sched-design-CFS.rst <sched_design_CFS>`
> > +:Translator: Sergio González Collado <sergio.collado@gmail.com>
> > +
> > +.. _sp_sched_desing_CFS:
> > +
> > +====================
> > +Gestor de tareas CFS
> > +====================
> > +
> > +1.  VISIÓN GENERAL
> > +==================
> > +
> > +CFS viene de las siglas en inglés de "Gestor te tareas totalmente justo"
>
>
> Change 'te' to 'de'. For the rest of the review, I'll say instead:
> 's/old/new', in this case, s/te/de.
>
>
> > +("Completely Fair Scheduler"), y es el nuevo gestor de tareas de escritorio
> > +implementado por Ingo Molnar e integrado en Linux 2.6.23. Es el sustituto de
> > +el previo gestor de tareas SCHED_OTHER.
>
>
> Although I usually don't do this, considering that CFS is no longer the
> most recent scheduler, let's add a note here:
>
> Nota: El planificador EEVDF fue incorporado más recientemente al kernel.
>
>
> > +
> > +El 80% del diseño de CFS puede ser resumido en una única frase: CFS
> > +básicamente modela una "CPU ideal, precisa y multi-tarea" sobre hardware
> > +real.
> > +
> > +"una CPU multitarea ideal" es una CPU (inexistente :-)) que tiene un 100%
> > +de potencia y que puede ejecutar cualquier tarea exactamente a la misma
> > +velocidad, en paralelo, y cada una a 1/n velocidad. Por ejemplo, si hay dos
> > +tareas ejecutándose, entonces cada una usa un 50% de la potencia --- es decir,
> > +como si se ejecutaran en paralelo.
> > +
> > +En un hardware real, se puede ejecutar una única tarea a la vez, así que
>
>
> s/En un hardware/En hardware
>
>
> > +se ha usado el concepto de "tiempo de ejecución virtual". El tiempo
> > +de ejecución virtual de una tarea, específica cuando la siguiente porción
>
>
> s/tarea,/tarea
>
>
> > +de ejecución podría empezar en la CPU ideal multi-tarea descrita anteriormente.
> > +En la práctica, el tiempo de ejecución virtual de una tarea es el
> > +tiempo de ejecución real normalizado con respecto al número total de
> > +tareas ejecutándose.
> > +
> > +
> > +2.  UNOS CUANTOS DETALLES DE IMPLEMENTACIÓN
> > +===========================================
> > +
> > +En CFS, el tiempo de ejecución virtual se expresa y se monitoriza por
> > +cada tarea, en su valor de p->se.vruntime (en unidades de nanosegundos).
> > +De este modo, es posible temporizar con precisión y medir el "tiempo
> > +de CPU esperado" que una tarea debería tener.
> > +
> > +Un pequeño detalle: en hardware "ideal", en cualquier momento todas las
> > +tareas pueden tener el mismo valor de p->se.vruntime --- i.e., tareas
> > +se podrían ejecutar simultáneamente y ninguna tarea podría escaparse del
> > +"balance" de la partición "ideal" del tiempo compartido de la CPU.
> > +
> > +La lógica de elección del tareas de CFS se basa en el valor de p->se.vruntime
> > +y por tanto es muy sencilla: siempre intenta ejecutar la tarea con el valor
> > +p->se.vruntime más pequeño (i.e., la tarea que se ha ejecutado menos hasta el
> > +momento). CFS siempre intenta dividir el espacio de tiempo entre tareas
> > +en ejecución tan próximo a la "ejecución multitarea ideal del hardware" como
> > +sea posible.
> > +
> > +El resto del diseño de CFS simplemente se escapa de este simple concepto,
> > +con unos cuantos añadidos como los niveles "nice" ("nice" significa "amable"
> > +en inglés), multi-tarea y varias variantes del algoritmo para identificar
> > +tareas "durmiendo".
> > +
> > +
> > +3.  EL ÁRBOL ROJO-NEGRO
> > +=======================
> > +
> > +El diseño de CFS es bastante radical: no utiliza las antiguas estructuras
> > +de datos para las colas de ejecución (en inglés "runqueues"), pero usa una
> > +estructura de árbol rojo-negro (en inglés "red-black tree") ordenado cronológicamente
> > +para construir un línea de ejecución en el futuro, y por eso no tiene ningún
> > +artificio de "cambio de tareas" (algo que previamente era usado por el gestor
> > +anterior y RSDL/SD).
> > +
> > +CFS también mantiene el valor de rq->cfs.min_vruntime, el cual crece
> > +monotónicamente siguiendo el valor más pequeño de vruntime de entre todas
> > +las tareas en la cola de ejecución. La cantidad total de trabajo realizado
> > +por el sistema es monitorizado usado min_vruntime; este valor es usado
> > +para situar las nuevas tareas en la parte izquierda del árbol tanto
> > +como sea posible.
> > +
> > +El valor total de tareas ejecutándose en la cola de ejecución es
> > +contabilizado mediante el valor rq->cfs.load, el cual es la suma de los
> > +de esas tareas que están en la cola de ejecución.
> > +
> > +CFS mantiene un árbol rojo-negro cronológiamente ordenado, donde todas las
>
>
> s/cronológiamente/cronológicamente
>
>
> > +tareas que pueden ser ejecutadas están ordenadas por su valor de
> > +p->se.vruntime. CFS selecciona la tarea más hacia la izquierda de este
> > +árbol y la mantiene. Según el sistema continúa, las tareas ejecutadas
> > +se ponen en este árbol más y más hacia la derecha --- lentamente pero
> > +de forma continuada dando una oportunidad a cada tarea de ser la que
> > +está "la más hacia la izquierda" y por tanto obtener la CPU una cantidad
> > +determinista de tiempo.
> > +
> > +Resumiendo, CFS funciona así: ejecuta una tarea un tiempo, y cuando la
> > +tarea se gestiona (o sucede un tic del gestor de tareas) se considera
> > +que el tiempo de uso de la CPU se ha completado, y se añade a
> > +p->se.vruntime. Una vez p->se.vruntime ha aumentado lo suficiente como
> > +para que otra tarea sea "la tarea más hacia la izquierda" del árbol
> > +rojo-negro ordenado cronológicamente esta mantienen (más una cierta pequeña
> > +cantidad de distancia relativa a la tarea más hacia la izquierda para
> > +que no se sobre-reserven tareas y perjudique a la cache), entonces la
> > +nueva tarea "que está a la izquierda del todo", es la que se elige
> > +para que se ejecute, y la tarea en ejecución es interrumpida.
> > +
> > +4.  ALGUNAS CARACTERÍSTICAS DE CFS
> > +==================================
> > +
> > +CFS usa una granularidad de nanosegundos y no depende de ningún
> > +jiffie o detalles como HZ. De este modo el gestor de tareas CFS no tiene
>
>
> s/modo/modo,
>
>
> > +noción de "ventanas de tiempo" de la forma en que tenía el gestor de
> > +tareas previo, y tampoco tiene heurísticos. Únicamente hay un parámetro
> > +central ajustable (se ha de cambiar en CONFIG_SCHED_DEBUG):
> > +
> > +   /sys/kernel/debug/sched/base_slice_ns
> > +
> > +El cual puede ser usado para afinar desde el gestor de tareas del "escritorio"
> > +(i.e., bajas latencias) hacia cargas de "servidor" (i.e., bueno con
> > +procesamientos). Su valor por defecto es adecuado para tareas de escritorio.
> > +SCHED_BATCH también es gestionado por el gestor de tareas CFS.
> > +
> > +Debido a su diseño, el gestor de tareas CFS no es proclive a ninguno de los
> > +ataques que existen a día de hoy contra los heurísticos del gestor de tareas:
> > +fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c todos trabajan
> > +correctamente y no tienen impacto en la interacción y se comportan de la forma
> > +esperada.
> > +
> > +El gestor de tareas CFS tiene una gestión mucho más firme de los niveles
> > +"nice" y SCHED_BATCH que los previos gestores de tareas: ambos tipos de
> > +tareas están aisladas de forma más eficiente.
> > +
> > +El balanceo de tareas SMP ha sido rehecho/mejorado: el avance por las
> > +colas de ejecución de tareas ha desaparecido del código de balanceo de
> > +carga, y ahora se usan iteradores en la gestión de módulos. El balanceo
> > +del código ha sido simplificado como resultado esto.
> > +
> > +5.  Políticas de gestión de tareas
> > +==================================
> > +
> > +CFS implementa tres políticas de gestión de tareas:
> > +
> > +  - SCHED_NORMAL (tradicionalmente llamada SCHED_OTHER): Gestión de
> > +    tareas que se usan para tareas normales.
> > +
> > +  - SCHED_BATCH: No interrumpe tareas tan amenudo como las tareas
>
>
> s/amenudo/a menudo
>
>
> > +    normales harían, por eso permite a las tareas ejecutarse durante
> > +    ventanas de tiempo mayores y hace un uso más efectivo de las
> > +    caches pero al coste de la interactividad. Esto es adecuado
> > +    para trabajos de procesado de datos.
> > +
> > +  - SCHED_IDLE: Esta política es más débil incluso que nice 19, pero
> > +    no es un gestor "idle" para evitar caer en el problema de la
> > +    inversión de prioridades que causaría un bloqueo de la máquina
> > +    (deadlock).
> > +
> > +SCHED_FIFO/_RR se implementan en sched/rt.c y son específicos de
> > +POSIX.
> > +
> > +El comando chrt de util-linux-ng 2.13.1.1. puede asignar cualquiera de
> > +estas políticas excepto SCHED_IDLE.
> > +
> > +
> > +6.  CLASES DE GESTIÓN
> > +=====================
> > +
> > +El nuevo gestor de tareas CFS ha sido diseñado de tal modo para incluir
> > +"clases de gestión", una jerarquía ampliable de módulos que pueden tener
> > +distintas políticas de gestión de tareas. Estos módulos encapsulan los
> > +detalles de las politicas de gestion y son manejadas por el núcleo del
>
>
> s/gestion/gestión
>
>
> > +gestor de tareas sin que este tenga que presuponer mucho sobre estas clases.
> > +
> > +sched/fair.c implementa el gestor de tareas CFS descrito arriba.
>
>
> s/arriba/antes
>
>
> > +
> > +sched/rt.c implementa la semántica de SCHED_FIFO y SCHED_RR, de una forma
> > +más sencilla que el gestor de tareas anterior. Usa 100 colas de ejecución
> > +(por todos los 100 niveles de prioridad RT, en vez de las 140 que necesitaba
> > +el gestor de tareas anterior) y no necesita las listas de expiración.
> > +
> > +Las clases de gestión de tareas son implementadas por medio de la estructura
> > +sched_class, la cual tiene llamadas a las funciones que deben de llamarse
> > +cuando quiera que ocurra un evento interesante.
> > +
> > +Esta es la lista parcial de llamadas:
> > +
> > + - enqueue_task(...)
> > +
> > +   Llamada cuando una tarea entra en el estado de lista para ejecución.
> > +   Pone la entidad a ser gestionada (la tarea) en el árbol rojo-negro
> > +   e incrementa la variable nr_running.
> > +
> > + - dequeue_task(...)
> > +
> > +   Cuando una tarea deja de ser ejecutable, esta función se llama para
> > +   mantener a la entidad gestionada fuera del árbol rojo-negor. Esto
> > +   decrementa la variable nr_running.
> > +
> > + - yield_task(...)
> > +
> > +   Esta función es básicamente desencolar, seguido por encolar, a menos que
> > +   sysctl compat_yield esté activado; en ese caso, sitúa la entidad a gestionar
> > +   en la parte más hacia la derecha del árbol rojo-negro.
> > +
> > + - check_preempt_curr(...)
> > +
> > +   Esta función comprueba si una tarea que ha entrado en el estado de
> > +   poder ser ejecutada, podría reemplazar a la tarea que actualmente
> > +   se esté ejecutando.
> > +
> > + - pick_next_task(...)
> > +
> > +   Esta función elige la tarea más apropiada para ser ejecutada a continuación.
> > +
> > + - set_curr_task(...)
> > +
> > +   Esta función se llama cuando una tarea cambia su clase de gestión o
> > +   cambia su grupo de tareas.
> > +
> > + - task_tick(...)
> > +
> > +   Esta función es llamada la mayoría de las veces desde la función de tiempo
> > +   tick; esto puede llevar a un cambio de procesos. Esto dirige el reemplazo
> > +   de las tareas.
> > +
> > +
> > +7.  EXTENSIONES DE GRUPOS PARA CFS
> > +==================================
> > +
> > +Normalmente, el gestor de tareas gestiona tareas individuales e intenta
> > +proporcionar una cantidad justa de CPU a cada tarea. Algunas veces, puede
> > +ser deseable agrupar las tareas y proporcionarles una cantidad justa
> > +de tiempo de CPU a cada una de las tareas de ese grupo. Por ejemplo,
> > +podría ser deseable que primero se proporcione una cantidad justa de
> > +tiempo de CPU a cada usuario del sistema y después a cada tarea
> > +que pertenezca a un usuario.
> > +
> > +CONFIG_CGROUP_SCHED destaca en conseguir exactamente eso. Permite a las
> > +tareas ser agrupadas y divide el tiempo de CPU de forma just entre esos
> > +grupos.
> > +
> > +CONFIG_RT_GROUP_SCHED permite agrupar tareas de tiempo real (i.e.,
> > +SCHED_FIFO y SCHED_RR).
> > +
> > +CONFIG_FAIR_GROUP_SCHED permite agrupar tareas de CFS (i.e., SCHED_NORMAL y
> > +SCHED_BATCH).
> > +
> > +Estas opciones necesitan CONFIG_CGROUPS para ser definidas, y permitir
> > +al administrador crear grupos arbitrarios de tareas, usando el pseudo
> > +sistema de archivos "cgroup". Vease la documentación para más información
> > +sobre este sistema de archivos: Documentation/admin-guide/cgroup-v1/cgroups.rst
> > +
> > +Cuando CONFIG_FAIR_GROUP_SCHED es definido, un archivo
> > +"cpu.shares" es creado por cada grupo creado usado en el pseudo
> > +sistema de archivos. Véanse por ejemplo los pasos a continuación
> > +para crear grupos de tareas y modificar cuanto comparten de la CPU
> > +usando el pseudo sistema de archivos "cgroup" ::
> > +
> > +     # mount -t tmpfs cgroup_root /sys/fs/cgroup
> > +     # mkdir /sys/fs/cgroup/cpu
> > +     # mount -t cgroup -ocpu none /sys/fs/cgroup/cpu
> > +     # cd /sys/fs/cgroup/cpu
> > +
> > +     # mkdir multimedia      # crear un grupo de tareas "multimedia"
> > +     # mkdir browser         # crear un grupo de tareas "browser"
> > +
> > +     # #Configurar el grupo multimedia para tener el doble de tiempo de CPU
> > +     # #que el grupo browser
> > +
> > +     # echo 2048 > multimedia/cpu.shares
> > +     # echo 1024 > browser/cpu.shares
> > +
> > +     # firefox &     # Lanzar firefox y moverlo al grupo "browser"
> > +     # echo <firefox_pid> > browser/tasks
> > +
> > +     # #Lanzar gmplayer (o su programa favorito de reproducción de películas)
> > +     # echo <movie_player_pid> > multimedia/tasks
>
>
> Sergio, thank you for contributing to the documentation in Spanish. This is
> excellent work! Please, send a v2 with these minor changes, and you can
> add:
> Reviewed-by: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
> Thanks,
> Carlos
>