From nobody Sat Feb 7 13:41:25 2026 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF57B1DA4D; Sun, 7 Jul 2024 19:50:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720381861; cv=none; b=K6y4G7c3QxRhd1Sv0L15twX4nKx9Ta4tn/2Rh8/fioyy2bLBjvRVRU1wszWvchYbo+v7FEVX16OvNnxmYL33JO6MPOiZ+52sIClaw9PDyjebGBkO8WWDLGoPKjGE/B9v2s3SIglPjou3mVeM981tjrqZR27Tc46gFmqD5AZFa5o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720381861; c=relaxed/simple; bh=Jjy7UAUL8yBXel5SbMF4r+YzkgVNd5gnL5SCoQqs5g8=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=o1b/cpZ+lr4mKRuzLay2hmiStgvrQKOsYnOjCE/+LdN6KpCecYl7pd7cjOd6j0foACyQN9rddxTHMzIE5oqELmZu2kpsMWItCFRyYD8CZIsu7Po1/IoYzXofSurOLKKvhWl9Ihb/ZQ1D+YKRet2L+YphnsRUIomTNCIhzn+pzBo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=W/9ikZIW; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="W/9ikZIW" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-42666fd6261so3377705e9.3; Sun, 07 Jul 2024 12:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720381857; x=1720986657; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=uUQJdzIK8Mf32u2XHaBTTFvuN4vfUeAW9J5u8vT3viY=; b=W/9ikZIWaDjew2/0TB0y0ElMA8Jvtg/YsLKGKW/gkJ6Kt1JGn4sI7ffA38B1CeZtty 8AX7MEMuKEFjbZtj4837TMqemfoasyNj5N2HqbAJbUVv5MBEf7OPEJhlxk9+It3uhJTd gRFYbgGIzOZAv11+fEao3G75OJ9VBVJwYY2/Yj4BOtuciPT8I1UIHabklld2jvjcECsS 23TzA1EuwNmWThTJPKrP+WF4ERsHtUbVWDSJTaDuxMURIJItOyr/oHisH71M3cULiefu U2VktxH5WIW5h4bWk+IrfO9iLmNAniV6CsDMVOjSViaYDfeEaEd14SxG2XewcjD8jc8y 8D2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720381857; x=1720986657; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uUQJdzIK8Mf32u2XHaBTTFvuN4vfUeAW9J5u8vT3viY=; b=FSUYjukB8v39593kMEIPF/nHMDpNzL5rwr+rjiqUWI6s9AM0hBaOIdvPekjb5z9UBk mBZXHF4cGfXbZEz1Q9LLjLCNQ1z8wg/OsvoWqX0hg4B0UBPJBtkpS67jbwoPlqPSmY2C skJ3m09W3ny2fUe5SGXqnjxlvRxUaEyB5WTOzdEysdqe+ZfgGk8fxDBkuHmjgbZpgJHl qFqlBl/rvGjxgwtnfA3PGngshDxriRVD1H0XZ6C/LLufzqSj+645JdJd6JSVjs7w7U9N 9tcChneQJpxWRYXE0fAsVd4SKFTnQc9QraC4jCc9ufd4s/6rT/mOY3jKlQcZB0R6LWuh n+PA== X-Forwarded-Encrypted: i=1; AJvYcCUsVx6tyyRqkFmNBsJ3qVhc+8O3nRLdM/kFwnu/2/dXtGU76enhfms1ohsOPMPX2jXWPbov1IfqZ+a2j7dfvfHGcC8/2GinDXaO54ty X-Gm-Message-State: AOJu0YxwHR7JlGm59pJ11xaq2Hpyy/bgW0/YdDgGsuPbtQaIn0vWEihl uvmMQgWNko72/X4GEdK9/CIraEto+q+X35eRK+LIGaWg4z9oN8KsGEduiogx X-Google-Smtp-Source: AGHT+IEl6EhkVlFRmxapmIhmYOcC21o5tblGq0Qa9ArdqU9sQJsPQND3KeqyL763b2oyUE8eTFk8BA== X-Received: by 2002:a05:600c:4da5:b0:426:6099:6eaa with SMTP id 5b1f17b1804b1-4266099726amr25237505e9.26.1720381856835; Sun, 07 Jul 2024 12:50:56 -0700 (PDT) Received: from laptop.home (83.50.134.37.dynamic.jazztel.es. [37.134.50.83]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-36791d7a93bsm12084507f8f.81.2024.07.07.12.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jul 2024 12:50:56 -0700 (PDT) From: =?UTF-8?q?Sergio=20Gonz=C3=A1lez=20Collado?= To: Jonathan Corbet , Ingo Molnar , Mukesh Kumar Chaurasiya , Shrikanth Hegde , Wenyu Huang , Carlos Bilbao Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, bilbao@vt.edu, =?UTF-8?q?Sergio=20Gonz=C3=A1lez=20Collado?= Subject: [PATCH v2] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst Date: Sun, 7 Jul 2024 21:50:47 +0200 Message-Id: <20240707195047.14359-1-sergio.collado@gmail.com> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Translate Documentation/scheduler/sched-design-CFS.rst into Spanish Signed-off-by: Sergio Gonz=C3=A1lez Collado Reviewed-by: Carlos Bilbao --- v1 -> v2: Corrected typos and added a note about EEVDF --- 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 | 277 ++++++++++++++++++ 4 files changed, 288 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/s= cheduler/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: + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CFS Scheduler =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/tra= nslations/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=C3=B1ol =20 process/index wrappers/memory-barriers + scheduler/index diff --git a/Documentation/translations/sp_SP/scheduler/index.rst b/Documen= tation/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.rs= t b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst new file mode 100644 index 000000000000..90a153cad4e8 --- /dev/null +++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst @@ -0,0 +1,277 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/scheduler/sched-design-CFS.rst ` +:Translator: Sergio Gonz=C3=A1lez Collado + +.. _sp_sched_desing_CFS: + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Gestor de tareas CFS +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +1. VISI=C3=93N GENERAL +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +CFS viene de las siglas en ingl=C3=A9s de "Gestor de tareas totalmente jus= to" +("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. + +Nota: El planificador EEVDF fue incorporado m=C3=A1s recientemente al kern= el. + +El 80% del dise=C3=B1o de CFS puede ser resumido en una =C3=BAnica frase: = CFS +b=C3=A1sicamente modela una "CPU ideal, precisa y multi-tarea" sobre hardw= are +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=C3=A1ndose, entonces cada una usa un 50% de la potencia --- = es decir, +como si se ejecutaran en paralelo. + +En hardware real, se puede ejecutar una =C3=BAnica tarea a la vez, as=C3= =AD que +se ha usado el concepto de "tiempo de ejecuci=C3=B3n virtual". El tiempo +de ejecuci=C3=B3n virtual de una tarea espec=C3=ADfica cuando la siguiente= porci=C3=B3n +de ejecuci=C3=B3n podr=C3=ADa empezar en la CPU ideal multi-tarea descrita= anteriormente. +En la pr=C3=A1ctica, el tiempo de ejecuci=C3=B3n virtual de una tarea es el +tiempo de ejecuci=C3=B3n real normalizado con respecto al n=C3=BAmero tota= l de +tareas ejecut=C3=A1ndose. + + +2. UNOS CUANTOS DETALLES DE IMPLEMENTACI=C3=93N +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +En CFS, el tiempo de ejecuci=C3=B3n 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=C3=B3n y medir el "tiempo +de CPU esperado" que una tarea deber=C3=ADa tener. + +Un peque=C3=B1o detalle: en hardware "ideal", en cualquier momento todas l= as +tareas pueden tener el mismo valor de p->se.vruntime --- i.e., tareas +se podr=C3=ADan ejecutar simult=C3=A1neamente y ninguna tarea podr=C3=ADa = escaparse del +"balance" de la partici=C3=B3n "ideal" del tiempo compartido de la CPU. + +La l=C3=B3gica de elecci=C3=B3n 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=C3=A1s peque=C3=B1o (i.e., la tarea que se ha ejecutado m= enos hasta el +momento). CFS siempre intenta dividir el espacio de tiempo entre tareas +en ejecuci=C3=B3n tan pr=C3=B3ximo a la "ejecuci=C3=B3n multitarea ideal d= el hardware" como +sea posible. + +El resto del dise=C3=B1o de CFS simplemente se escapa de este simple conce= pto, +con unos cuantos a=C3=B1adidos como los niveles "nice" ("nice" significa "= amable" +en ingl=C3=A9s), multi-tarea y varias variantes del algoritmo para identif= icar +tareas "durmiendo". + + +3. EL =C3=81RBOL ROJO-NEGRO +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +El dise=C3=B1o de CFS es bastante radical: no utiliza las antiguas estruct= uras +de datos para las colas de ejecuci=C3=B3n (en ingl=C3=A9s "runqueues"), pe= ro usa una +estructura de =C3=A1rbol rojo-negro (en ingl=C3=A9s "red-black tree") orde= nado cronol=C3=B3gicamente +para construir un l=C3=ADnea de ejecuci=C3=B3n en el futuro, y por eso no = tiene ning=C3=BAn +artificio de "cambio de tareas" (algo que previamente era usado por el ges= tor +anterior y RSDL/SD). + +CFS tambi=C3=A9n mantiene el valor de rq->cfs.min_vruntime, el cual crece +monot=C3=B3nicamente siguiendo el valor m=C3=A1s peque=C3=B1o de vruntime = de entre todas +las tareas en la cola de ejecuci=C3=B3n. La cantidad total de trabajo real= izado +por el sistema es monitorizado usado min_vruntime; este valor es usado +para situar las nuevas tareas en la parte izquierda del =C3=A1rbol tanto +como sea posible. + +El valor total de tareas ejecut=C3=A1ndose en la cola de ejecuci=C3=B3n es +contabilizado mediante el valor rq->cfs.load, el cual es la suma de los +de esas tareas que est=C3=A1n en la cola de ejecuci=C3=B3n. + +CFS mantiene un =C3=A1rbol rojo-negro cronol=C3=B3gicamente ordenado, dond= e todas las +tareas que pueden ser ejecutadas est=C3=A1n ordenadas por su valor de +p->se.vruntime. CFS selecciona la tarea m=C3=A1s hacia la izquierda de este +=C3=A1rbol y la mantiene. Seg=C3=BAn el sistema contin=C3=BAa, las tareas = ejecutadas +se ponen en este =C3=A1rbol m=C3=A1s y m=C3=A1s hacia la derecha --- lenta= mente pero +de forma continuada dando una oportunidad a cada tarea de ser la que +est=C3=A1 "la m=C3=A1s hacia la izquierda" y por tanto obtener la CPU una = cantidad +determinista de tiempo. + +Resumiendo, CFS funciona as=C3=AD: 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=C3=B1ade a +p->se.vruntime. Una vez p->se.vruntime ha aumentado lo suficiente como +para que otra tarea sea "la tarea m=C3=A1s hacia la izquierda" del =C3=A1r= bol +rojo-negro ordenado cronol=C3=B3gicamente esta mantienen (m=C3=A1s una cie= rta peque=C3=B1a +cantidad de distancia relativa a la tarea m=C3=A1s hacia la izquierda para +que no se sobre-reserven tareas y perjudique a la cache), entonces la +nueva tarea "que est=C3=A1 a la izquierda del todo", es la que se elige +para que se ejecute, y la tarea en ejecuci=C3=B3n es interrumpida. + +4. ALGUNAS CARACTER=C3=8DSTICAS DE CFS +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +CFS usa una granularidad de nanosegundos y no depende de ning=C3=BAn +jiffie o detalles como HZ. De este modo, el gestor de tareas CFS no tiene +noci=C3=B3n de "ventanas de tiempo" de la forma en que ten=C3=ADa el gesto= r de +tareas previo, y tampoco tiene heur=C3=ADsticos. =C3=9Anicamente hay un pa= r=C3=A1metro +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 "escrito= rio" +(i.e., bajas latencias) hacia cargas de "servidor" (i.e., bueno con +procesamientos). Su valor por defecto es adecuado para tareas de escritori= o. +SCHED_BATCH tambi=C3=A9n es gestionado por el gestor de tareas CFS. + +Debido a su dise=C3=B1o, el gestor de tareas CFS no es proclive a ninguno = de los +ataques que existen a d=C3=ADa de hoy contra los heur=C3=ADsticos del gest= or de tareas: +fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c todos trabajan +correctamente y no tienen impacto en la interacci=C3=B3n y se comportan de= la forma +esperada. + +El gestor de tareas CFS tiene una gesti=C3=B3n mucho m=C3=A1s firme de los= niveles +"nice" y SCHED_BATCH que los previos gestores de tareas: ambos tipos de +tareas est=C3=A1n aisladas de forma m=C3=A1s eficiente. + +El balanceo de tareas SMP ha sido rehecho/mejorado: el avance por las +colas de ejecuci=C3=B3n de tareas ha desaparecido del c=C3=B3digo de balan= ceo de +carga, y ahora se usan iteradores en la gesti=C3=B3n de m=C3=B3dulos. El b= alanceo +del c=C3=B3digo ha sido simplificado como resultado esto. + +5. Pol=C3=ADticas de gesti=C3=B3n de tareas +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +CFS implementa tres pol=C3=ADticas de gesti=C3=B3n de tareas: + + - SCHED_NORMAL (tradicionalmente llamada SCHED_OTHER): Gesti=C3=B3n de + tareas que se usan para tareas normales. + + - SCHED_BATCH: No interrumpe tareas tan a menudo como las tareas + normales har=C3=ADan, por eso permite a las tareas ejecutarse durante + ventanas de tiempo mayores y hace un uso m=C3=A1s efectivo de las + caches pero al coste de la interactividad. Esto es adecuado + para trabajos de procesado de datos. + + - SCHED_IDLE: Esta pol=C3=ADtica es m=C3=A1s d=C3=A9bil incluso que nice= 19, pero + no es un gestor "idle" para evitar caer en el problema de la + inversi=C3=B3n de prioridades que causar=C3=ADa un bloqueo de la m=C3= =A1quina + (deadlock). + +SCHED_FIFO/_RR se implementan en sched/rt.c y son espec=C3=ADficos de +POSIX. + +El comando chrt de util-linux-ng 2.13.1.1. puede asignar cualquiera de +estas pol=C3=ADticas excepto SCHED_IDLE. + + +6. CLASES DE GESTI=C3=93N +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +El nuevo gestor de tareas CFS ha sido dise=C3=B1ado de tal modo para inclu= ir +"clases de gesti=C3=B3n", una jerarqu=C3=ADa ampliable de m=C3=B3dulos que= pueden tener +distintas pol=C3=ADticas de gesti=C3=B3n de tareas. Estos m=C3=B3dulos enc= apsulan los +detalles de las politicas de gesti=C3=B3n y son manejadas por el n=C3=BAcl= eo del +gestor de tareas sin que este tenga que presuponer mucho sobre estas clase= s. + +sched/fair.c implementa el gestor de tareas CFS descrito antes. + +sched/rt.c implementa la sem=C3=A1ntica de SCHED_FIFO y SCHED_RR, de una f= orma +m=C3=A1s sencilla que el gestor de tareas anterior. Usa 100 colas de ejecu= ci=C3=B3n +(por todos los 100 niveles de prioridad RT, en vez de las 140 que necesita= ba +el gestor de tareas anterior) y no necesita las listas de expiraci=C3=B3n. + +Las clases de gesti=C3=B3n de tareas son implementadas por medio de la est= ructura +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=C3=B3= n. + Pone la entidad a ser gestionada (la tarea) en el =C3=A1rbol rojo-negro + e incrementa la variable nr_running. + + - dequeue_task(...) + + Cuando una tarea deja de ser ejecutable, esta funci=C3=B3n se llama para + mantener a la entidad gestionada fuera del =C3=A1rbol rojo-negor. Esto + decrementa la variable nr_running. + + - yield_task(...) + + Esta funci=C3=B3n es b=C3=A1sicamente desencolar, seguido por encolar, = a menos que + sysctl compat_yield est=C3=A9 activado; en ese caso, sit=C3=BAa la enti= dad a gestionar + en la parte m=C3=A1s hacia la derecha del =C3=A1rbol rojo-negro. + + - check_preempt_curr(...) + + Esta funci=C3=B3n comprueba si una tarea que ha entrado en el estado de + poder ser ejecutada, podr=C3=ADa reemplazar a la tarea que actualmente + se est=C3=A9 ejecutando. + + - pick_next_task(...) + + Esta funci=C3=B3n elige la tarea m=C3=A1s apropiada para ser ejecutada = a continuaci=C3=B3n. + + - set_curr_task(...) + + Esta funci=C3=B3n se llama cuando una tarea cambia su clase de gesti=C3= =B3n o + cambia su grupo de tareas. + + - task_tick(...) + + Esta funci=C3=B3n es llamada la mayor=C3=ADa de las veces desde la func= i=C3=B3n de tiempo + tick; esto puede llevar a un cambio de procesos. Esto dirige el reempla= zo + de las tareas. + + +7. EXTENSIONES DE GRUPOS PARA CFS +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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=C3=ADa ser deseable que primero se proporcione una cantidad justa de +tiempo de CPU a cada usuario del sistema y despu=C3=A9s 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=C3=B3n para m=C3=A1s in= formaci=C3=B3n +sobre este sistema de archivos: Documentation/admin-guide/cgroup-v1/cgroup= s.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=C3=A9anse por ejemplo los pasos a continuaci=C3=B3n +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 > browser/tasks + + # #Lanzar gmplayer (o su programa favorito de reproducci=C3=B3n de pel=C3= =ADculas) + # echo > multimedia/tasks --=20 2.39.2