From nobody Sat Feb 7 15:09:50 2026 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 67C2E482D3; Sat, 6 Jul 2024 13:23:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720272186; cv=none; b=epF8Gxt88rtcomVYAGbEnKLSbI4mD7TMQEW77lZbt959jzubVvwip7gUSz5KsZJryzEYOF6h45gZ0kfnGJ5YTzFQNKLZse4GzRJ/FUrS0830NN8RXrL9i2gW6pVlju0LolCbfewWepVunOp8VXpj0/VHWydFivuLXlFD5gVFdTI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720272186; c=relaxed/simple; bh=Arqr2O+E26dOPVE/MiOy1W5JC9TdNFDPmY+8IKbx3l0=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=g4+DSIJ+t6ppHd/sjrra9xqO9qDsTR3YSzntcht33+nFxQ9sJ1rWLwbjTqwO5JBOiARiIYDW2QvBDSD3kk+R2PLJrPQQEbZf7gBO3GloNjad8c/lwJSzRzzrAgU8s2wrjFDQ4I1bX6WYMyqgJuMtQFr5jx9GJ+YRrVP7U2MVd0Y= 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=efvmfBtK; arc=none smtp.client-ip=209.85.221.53 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="efvmfBtK" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-36796a9b636so1773484f8f.2; Sat, 06 Jul 2024 06:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720272183; x=1720876983; 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=HCG9bhtoXSHvRQi19xQn5JCPOGveVxUx3KcKQAi2HaE=; b=efvmfBtK77yF2+mPhmnSAZozx5WDmcMY4JtI3h7RaldxioVXmxNLFCNth0BwUQVG8X +t4WE/eKa0QYA4u39EQDI+QqEqEKwHB9msGPQLiuTXDRiUzBTc9ojv4KbsNF/xofp+EQ 2PHHs/9uQiQLg5PoqWUiBtwFkeWzHY4rf6721TgmVP1gfjoV3p2u+P1dVqJ0qpoVTKDJ GO1EZ5erjoVLpfsHweoWy1ktI9VFfYfrkX8ypS+YmxcUsNLhcDpIGC9eF0kPNbfLwi0z dmh0r4ZywvUZrIh9oAuKEwpSRqLIt4E/PAv2FXs8X50GxWqmCf2EIWjBAZPFZtKFhdDW i50A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720272183; x=1720876983; 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=HCG9bhtoXSHvRQi19xQn5JCPOGveVxUx3KcKQAi2HaE=; b=IhKG15SwgjJld13dgq1wOHjAV/9EhrNBxxpRiK29H6cYQiQO0LzZO7cTw27Qa3zszu 15x7yev++uSqI8Nvvt4tSxXTpjGUpK0qisyMgBAOo7mF10pGmCOK1DyPDYTRmzm0KCx5 LH+W1XpEPNEXDD/rk2lVGlkyw0KBdV8wc8+hLITqa+rdG/70wlnl5a1j/oCDwO9SLY3Z /+IVv4UWjhRFMqhosmNl/pu84NtLKTpCigcSxmmYwZmN8tyPc5R9T+89PFrPGx3cUspm Jp9WXOvG2BWfn7KQR8wogc02OrLPrOJLk4Z5rKI5G8Zb7HCayvhoA7LAW0iijmtGIdJm ANpg== X-Forwarded-Encrypted: i=1; AJvYcCWC4c93MRnPK1R3CXOqzNqrsM2V04qLT29OoS5XITY4mw4cqxf5NijH1JUb2VWPfbJEqP44vd6++q20W5Qk1QyUqw63Z9LrujQuVaaJaWuszwmqfmHC1H7MGd+CIilyX5ia3DpURcM3 X-Gm-Message-State: AOJu0YwVBGE1JWsIrvyNFTQxz2s33EKc8wgC/uWUbl9d3V+30icgaKbL 4Mui0lD6KTp982miJpY8ZEgMo8P5pegWFc47mnPF3gD1KZqnuh4B X-Google-Smtp-Source: AGHT+IHpcaqmPXPT56Wm2B1lipm05Y/XcJ4NPvjFqSgSW0V4gLGrZftGZ9fDNoCxikIGPlYs89gRpQ== X-Received: by 2002:a5d:4cc1:0:b0:365:b695:ef76 with SMTP id ffacd0b85a97d-3679dd34179mr4479510f8f.36.1720272182433; Sat, 06 Jul 2024 06:23:02 -0700 (PDT) Received: from laptop.home (83.50.134.37.dynamic.jazztel.es. [37.134.50.83]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4264a25b724sm94886665e9.38.2024.07.06.06.23.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jul 2024 06:23:02 -0700 (PDT) From: =?UTF-8?q?Sergio=20Gonz=C3=A1lez=20Collado?= To: Jonathan Corbet , Ingo Molnar , Mukesh Kumar Chaurasiya , Shrikanth Hegde , Wenyu Huang Cc: Carlos Bilbao , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, bilbao@vt.edu, =?UTF-8?q?Sergio=20Gonz=C3=A1lez=20Collado?= Subject: [PATCH] docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst Date: Sat, 6 Jul 2024 15:22:01 +0200 Message-Id: <20240706132201.26136-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 --- 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/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..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 ` +: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 te 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. + +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 un 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 siguient= e 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=B3giamente ordenado, donde= 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 amenudo 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 gestion y son manejadas por el n=C3=BAcleo 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 arriba. + +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