Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst- Extension
.rst- Size
- 12085 bytes
- Lines
- 278
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. 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 de 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
del previo gestor de tareas SCHED_OTHER. Hoy en día se está abriendo camino
para el gestor de tareas EEVDF, cuya documentación se puede ver en
Documentation/scheduler/sched-eevdf.rst
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 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
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.