* [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst @ 2024-07-06 13:22 Sergio González Collado 2024-07-06 19:00 ` Carlos Bilbao 0 siblings, 1 reply; 3+ messages in thread From: Sergio González Collado @ 2024-07-06 13:22 UTC (permalink / raw) To: Jonathan Corbet, Ingo Molnar, Mukesh Kumar Chaurasiya, Shrikanth Hegde, Wenyu Huang Cc: Carlos Bilbao, linux-doc, linux-kernel, bilbao, 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 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst 2024-07-06 13:22 [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst Sergio González Collado @ 2024-07-06 19:00 ` Carlos Bilbao 2024-07-07 20:08 ` Sergio González Collado 0 siblings, 1 reply; 3+ messages in thread From: Carlos Bilbao @ 2024-07-06 19:00 UTC (permalink / raw) To: Sergio González Collado, Jonathan Corbet, Ingo Molnar, Mukesh Kumar Chaurasiya, Shrikanth Hegde, Wenyu Huang Cc: linux-doc, linux-kernel, 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst 2024-07-06 19:00 ` Carlos Bilbao @ 2024-07-07 20:08 ` Sergio González Collado 0 siblings, 0 replies; 3+ messages in thread From: Sergio González Collado @ 2024-07-07 20:08 UTC (permalink / raw) To: Carlos Bilbao Cc: Jonathan Corbet, Ingo Molnar, Mukesh Kumar Chaurasiya, Shrikanth Hegde, Wenyu Huang, linux-doc, linux-kernel, bilbao 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 > ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-07-07 20:09 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-07-06 13:22 [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst Sergio González Collado 2024-07-06 19:00 ` Carlos Bilbao 2024-07-07 20:08 ` Sergio González Collado
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).