From nobody Sat Nov 30 03:45:00 2024 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 EE16B84D02; Thu, 12 Sep 2024 17:12:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726161137; cv=none; b=b9GIFMGRlKX33iBtpBo9IJDO51vNogLa5Mz1eOAx7UugNFDZpynxGoI9m+9rPL2akS2rIKZyB0e1zXQBpTzuLaOkoyurR6K6clIKX3g5gH4MLAam8Ijvof+65CO86C7iNAc/x3GjU7IGD4QF3ZdfROIP698NcMvK8UhlgOGtLp8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726161137; c=relaxed/simple; bh=7qwqd0uHY7HDNUxm3GfKc1yKsT0UOQghv2tvdOF8mwQ=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=JwnylwAR8/kpqnrDZyuSjv2I4pIWrcZy3fbEfXxm56QEahj0DJ8WBjtuCEw7frUXktjjVkm7N2/exF1eoiRaN32B3ob7tfV/uWOa0ZqA1KDV42Vi97IeVEi3NoOgBHrcASYpAMAmkh4hmHh13IU43LG0r84zp8oULgjl1nVLC98= 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=UFLaDt01; arc=none smtp.client-ip=209.85.221.54 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="UFLaDt01" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-371ba7e46easo976246f8f.0; Thu, 12 Sep 2024 10:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726161133; x=1726765933; 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=vJQDErB6mTzQ7MKAk9Z8g1TvJHHvyf5txaqbat1RPAo=; b=UFLaDt01VmQ97BeX/A0765kanZSlSOfjRyFKyrms4rY2wXIcrNnISBZwxUBXuJ5YGO uJZGHsz0a9vFnnhqhKP2qG+Id9CkRUcY2lg/nJmmzM4MFdcVed2s+heC7AK3cFVzIcn2 1cbS9wLmiwlI+pjBVT1t89KahTDNpCkIC4P2W9P3cbrcgfLCMuu3uqBbvBbWDECARIfL GKvXTFRbUBRpEMo8sYfDNJMygjEz5OICsSwys/40NpiIPxDuGpk1V21XZRoyxTvk8qTR WHqPHEzUlcaZ2To1y8T0KuJ3BWUvgGhTXaaAHpybuvpze7H1D+HkTW/xs6H0E8bRKWZ1 HhlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726161133; x=1726765933; 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=vJQDErB6mTzQ7MKAk9Z8g1TvJHHvyf5txaqbat1RPAo=; b=rQ0fPWO2BJMi3OhHWh5QzMZo5fTklq1j7rCfItCaRQel4xZaBSQIZ81GWBWEC8MjZe 7mafEWqGjJmeU3W7sCnE+w/+q61hafYwmUzJBtM4nM51X9dW1wSWkJHdyF0CZptv2xpn ZmMbGXizn0/C+foYye891wiC9OjWeJGmQoTiU3bHUw+A0y7Bto/4yKeEQvjRR8VHPyV2 Rb/elBV7XibnB1027yvZb+vZes394ND2OI0SB6M2yJRSyoaL623z9FVVIwTWx/xXAWca X84Hl+F1WA6fspBqpqx7FAsRDj8/VeStpMq7nmB5SrtE+5yN0S9p95zEaEbGpHC528Gc BvsQ== X-Forwarded-Encrypted: i=1; AJvYcCVXyjc011OdMDMJmDv9Z9RHlHtfhyxvavlNgy6G6flPfUSUbiwYkcIXUzMOsrV1gyn3GFgR0D/gqvNWBJ8=@vger.kernel.org X-Gm-Message-State: AOJu0Ywoc9izX+eEeCHbbl3tUEQdMAs2N4Fy16I1AvSZFVIvezYptrWk y/yGB8rZNFCTSZBTxssbm2xKd1O77+c853IHANNb9WpKFULWJl4N X-Google-Smtp-Source: AGHT+IGV0wlFGBSbprFADfLq368iFB7zle70zGrlQKvxJkN4Vlt65lB0UrtQoqF69VbJ8dSjdSavzw== X-Received: by 2002:a5d:6a92:0:b0:378:80ab:9968 with SMTP id ffacd0b85a97d-378c2cf45d0mr2092706f8f.17.1726161132103; Thu, 12 Sep 2024 10:12:12 -0700 (PDT) Received: from laptop.. (237.red-83-52-63.dynamicip.rima-tde.net. [83.52.63.237]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-378956761c6sm14882654f8f.61.2024.09.12.10.12.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Sep 2024 10:12:10 -0700 (PDT) From: =?UTF-8?q?Sergio=20Gonz=C3=A1lez=20Collado?= To: Jonathan Corbet , Bjorn Helgaas , Carlos Bilbao Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linuxfoundation.org, skhan@linuxfoundation.org, Ricardo.marliere@suse.com, =?UTF-8?q?Sergio=20Gonz=C3=A1lez=20Collado?= Subject: [PATCH v4] docs/sp_SP: Add translation for scheduler/sched-bwc.rst Date: Thu, 12 Sep 2024 19:11:44 +0200 Message-Id: <20240912171144.15398-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-bwc.rst into Spanish. Signed-off-by: Sergio Gonz=C3=A1lez Collado Reviewed-by: Carlos Bilbao --- v1 -> v2: initial patch --- v2 -> v3: failed patch --- v3 -> v4: corrected reviews --- .../translations/sp_SP/scheduler/index.rst | 1 + .../sp_SP/scheduler/sched-bwc.rst | 287 ++++++++++++++++++ 2 files changed, 288 insertions(+) create mode 100644 Documentation/translations/sp_SP/scheduler/sched-bwc.rst diff --git a/Documentation/translations/sp_SP/scheduler/index.rst b/Documen= tation/translations/sp_SP/scheduler/index.rst index 768488d6f001..3aef47ca87e0 100644 --- a/Documentation/translations/sp_SP/scheduler/index.rst +++ b/Documentation/translations/sp_SP/scheduler/index.rst @@ -6,3 +6,4 @@ :maxdepth: 1 =20 sched-design-CFS + sched-bwc diff --git a/Documentation/translations/sp_SP/scheduler/sched-bwc.rst b/Doc= umentation/translations/sp_SP/scheduler/sched-bwc.rst new file mode 100644 index 000000000000..3fbc34b5b34e --- /dev/null +++ b/Documentation/translations/sp_SP/scheduler/sched-bwc.rst @@ -0,0 +1,287 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/scheduler/sched-design-CFS.rst ` +:Translator: Sergio Gonz=C3=A1lez Collado + +.. _sp_sched_bwc: + +=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 con control de ancho de banda +=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 + +.. note:: + Este documento =C3=BAnicamente trata el control de ancho de banda de CP= Us + para SCHED_NORMAL. El caso de SCHED_RT se trata en Documentation/schedu= ler/sched-rt-group.rst + +El control de ancho de banda es una extensi=C3=B3n CONFIG_FAIR_GROUP_SCHED= que +permite especificar el m=C3=A1ximo uso disponible de CPU para un grupo o u= na jerarqu=C3=ADa. + +El ancho de banda permitido para un grupo de tareas se especifica usando u= na +cuota y un periodo. Dentro de un "periodo" (microsegundos), a un grupo +de tareas se le asigna hasta su "cuota" de tiempo de uso de CPU en +microsegundos. Esa cuota es asignada para cada CPU en colas de ejecuci=C3= =B3n +en porciones de tiempo de ejecuci=C3=B3n en la CPU seg=C3=BAn los hilos de= ejecuci=C3=B3n +del grupo de tareas van siendo candidatos a ejecutarse. Una vez toda la cu= ota +ha sido asignada cualquier petici=C3=B3n adicional de cuota resultar=C3=A1= en esos hilos +de ejecuci=C3=B3n siendo limitados/estrangulados. Los hilos de ejecuci=C3= =B3n limitados +no ser=C3=A1n capaces de ejecutarse de nuevo hasta el siguiente periodo cu= ando +la cuota sea restablecida. + +La cuota sin asignar de un grupo es monitorizada globalmente, siendo +restablecidas cfs_quota unidades al final de cada periodo. Seg=C3=BAn los +hilos de ejecuci=C3=B3n van consumiendo este ancho de banda, este se +transfiere a los "silos" de las cpu-locales en base a la demanda. La +cantidad transferida en cada una de esas actualizaciones es ajustable y +es descrito como un "slice". + +Caracter=C3=ADstica de r=C3=A1faga +-------------------------- + +Esta caracter=C3=ADstica toma prestado tiempo ahora, que en un futuro tend= r=C3=A1 que +devolver, con el coste de una mayor interferencia hacia los otros usuarios +del sistema. Todo acotado perfectamente. + +El tradicional control de ancho de banda (UP-EDF) es algo como: + + (U =3D \Sum u_i) <=3D 1 + +Esto garantiza dos cosas: que cada tiempo l=C3=ADmite de ejecuci=C3=B3n es= cumplido +y que el sistema es estable. De todas formas, si U fuese > 1, entonces +por cada segundo de tiempo de reloj de una tarea, tendr=C3=ADamos que +ejecutar m=C3=A1s de un segundo y obviamente no se cumplir=C3=ADa con el t= iempo +l=C3=ADmite de ejecuci=C3=B3n de la tarea, pero en el siguiente periodo de= ejecuci=C3=B3n +el tiempo l=C3=ADmite de la tarea estar=C3=ADa todav=C3=ADa m=C3=A1s lejos= , y nunca se tendr=C3=ADa +tiempo de alcanzar la ejecuci=C3=B3n, cayendo as=C3=AD en un fallo no acot= ado. + +La caracter=C3=ADstica de r=C3=A1faga implica que el trabajo de una tarea = no siempre +consuma totalmente la cuota; esto permite que se pueda describir u_i +como una distribuci=C3=B3n estad=C3=ADstica. + +Por ejemplo, se tiene u_i =3D {x,e}_i, donde x es el p(95) y x+e p(100) +(el tradicional WCET (WCET:Worst Case Execution Time: son las siglas +en ingl=C3=A9s para "peor tiempo de ejecuci=C3=B3n")). Esto efectivamente = permite +a u ser m=C3=A1s peque=C3=B1o, aumentando la eficiencia (podemos ejecutar = m=C3=A1s +tareas en el sistema), pero al coste de perder el instante l=C3=ADmite de +finalizaci=C3=B3n deseado de la tarea, cuando coincidan las peores +probabilidades. De todas formas, si se mantiene la estabilidad, ya que +cada sobre-ejecuci=C3=B3n se empareja con una infra-ejecuci=C3=B3n en tant= o x est=C3=A9 +por encima de la media. + +Es decir, sup=C3=B3ngase que se tienen 2 tareas, ambas espec=C3=ADficamente +con p(95), entonces tenemos p(95)*p(95) =3D 90.25% de probabilidad de +que ambas tareas se ejecuten dentro de su cuota asignada y todo +salga bien. Al mismo tiempo se tiene que p(5)*p(5) =3D 0.25% de +probabilidad que ambas tareas excedan su cuota de ejecuci=C3=B3n (fallo +garantizado de su tiempo final de ejecuci=C3=B3n). En alg=C3=BAn punto por +en medio, hay un umbral donde una tarea excede su tiempo l=C3=ADmite de +ejecuci=C3=B3n y la otra no, de forma que se compensan; esto depende de la +funci=C3=B3n de probabilidad acumulada espec=C3=ADfica de la tarea. + +Al mismo tiempo, se puede decir que el peor caso de sobrepasar el +tiempo l=C3=ADmite de ejecuci=C3=B3n ser=C3=A1 \Sum e_i; esto es una retra= so acotado +(asumiendo que x+e es de hecho el WCET). + +La interferencia cuando se usa una r=C3=A1faga se eval=C3=BAa por las posi= bilidades +de fallar en el cumplimiento del tiempo l=C3=ADmite y el promedio de WCET. +Los resultados de los tests han mostrado que cuando hay muchos cgroups o +una CPU est=C3=A1 infrautilizada, la interferencia es m=C3=A1s limitada. M= =C3=A1s detalles +se aportan en: https://lore.kernel.org/lkml/5371BD36-55AE-4F71-B9D7-B86DC3= 2E3D2B@linux.alibaba.com/ + +Gesti=C3=B3n: +-------- + +Cuota, periodo y r=C3=A1faga se gestionan dentro del subsistema de cpu por= medio +de cgroupfs. + +.. note:: + Los archivos cgroupfs descritos en esta secci=C3=B3n solo se aplican al= cgroup + v1. Para cgroup v2, ver :ref:`Documentation/admin-guide/cgroup-v2.rst <= cgroup-v2-cpu>`. + +- cpu.cfs_quota_us: tiempo de ejecuci=C3=B3n que se refresca cada periodo = (en microsegundos) +- cpu.cfs_period_us: la duraci=C3=B3n del periodo (en microsegundos) +- cpu.stat: exporta las estad=C3=ADsticas de limitaci=C3=B3n [explicado a = continuaci=C3=B3n] +- cpu.cfs_burst_us: el m=C3=A1ximo tiempo de ejecuci=C3=B3n acumulado (en = microsegundos) + +Los valores por defecto son:: + + cpu.cfs_period_us=3D100ms + cpu.cfs_quota_us=3D-1 + cpu.cfs_burst_us=3D0 + +Un valor de -1 para cpu.cfs_quota_us indica que el grupo no tiene ninguna +restricci=C3=B3n de ancho de banda aplicado, ese grupo se describe como un= grupo +con ancho de banda sin restringir. Esto representa el comportamiento +tradicional para CFS. + +Asignar cualquier valor (v=C3=A1lido) y positivo no menor que cpu.cfs_burs= t_us +definir=C3=A1 el l=C3=ADmite del ancho de banda. La cuota m=C3=ADnima perm= itida para +la cuota o periodo es 1ms. Hay tambi=C3=A9n un l=C3=ADmite superior en la = duraci=C3=B3n del +periodo de 1s. Existen restricciones adicionales cuando los l=C3=ADmites de +ancho de banda se usan de manera jer=C3=A1rquica, estos se explican en may= or +detalle m=C3=A1s adelante. + +Asignar cualquier valor negativo a cpu.cfs_quota_us eliminar=C3=A1 el l=C3= =ADmite de +ancho de banda y devolver=C3=A1 de nuevo al grupo a un estado sin restricc= iones. + +Un valor de 0 para cpu.cfs_burst_us indica que el grupo no puede acumular +ning=C3=BAn ancho de banda sin usar. Esto hace que el control del comporta= miento +tradicional del ancho de banda para CFS no cambie. Definir cualquier valor +(v=C3=A1lido) positivo no mayor que cpu.cfs_quota_us en cpu.cgs_burst_us d= efinir=C3=A1 +el l=C3=ADmite con el ancho de banda acumulado no usado. + +Cualquier actualizaci=C3=B3n a las especificaciones del ancho de banda usa= do +por un grupo resultar=C3=A1 en que se deje de limitar si est=C3=A1 en un e= stado +restringido. + +Ajustes globales del sistema +---------------------------- + +Por eficiencia el tiempo de ejecuci=C3=B3n es transferido en lotes desde u= na reserva +global y el "silo" de una CPU local. Esto reduce en gran medida la presi= =C3=B3n +por la contabilidad en grandes sistemas. La cantidad transferida cada vez +que se requiere una actualizaci=C3=B3n se describe como "slice". + +Esto es ajustable v=C3=ADa procfs:: + + /proc/sys/kernel/sched_cfs_bandwidth_slice_us (valor por defecto=3D5ms) + +Valores de "slice" m=C3=A1s grandes reducir=C3=A1n el costo de transferenc= ia, mientras +que valores m=C3=A1s peque=C3=B1os permitir=C3=A1n un control m=C3=A1s fin= o del consumo. + +Estad=C3=ADsticas +------------ + +Las estad=C3=ADsticas del ancho de banda de un grupo se exponen en 5 campo= s en cpu.stat. + +cpu.stat: + +- nr_periods: N=C3=BAmero de intervalos aplicados que han pasado. +- nr_throttled: N=C3=BAmero de veces que el grupo ha sido restringido/limi= tado. +- throttled_time: La duraci=C3=B3n de tiempo total (en nanosegundos) en las + que las entidades del grupo han sido limitadas. +- nr_bursts: N=C3=BAmero de periodos en que ha ocurrido una r=C3=A1faga. +- burst_time: Tiempo acumulado (en nanosegundos) en la que una CPU ha + usado m=C3=A1s de su cuota en los respectivos periodos. + +Este interfaz es de solo lectura. + +Consideraciones jer=C3=A1rquicas +--------------------------- + +La interfaz refuerza que el ancho de banda de una entidad individual +sea siempre factible, esto es: max(c_i) <=3D C. De todas maneras, +la sobre-suscripci=C3=B3n en el caso agregado est=C3=A1 expl=C3=ADcitament= e permitida +para hacer posible sem=C3=A1nticas de conservaci=C3=B3n de trabajo dentro = de una +jerarquia. + + e.g. \Sum (c_i) puede superar C + +[ Donde C es el ancho de banda de el padre, y c_i el de su hijo ] + +Hay dos formas en las que un grupo puede ser limitado: + + a. este consume totalmente su propia cuota en un periodo. + b. la cuota del padre es consumida totalmente en su periodo. + +En el caso b) anterior, incluso si el hijo pudiera tener tiempo de +ejecuci=C3=B3n restante, este no le ser=C3=A1 permitido hasta que el tiemp= o de +ejecuci=C3=B3n del padre sea actualizado. + +Advertencias sobre el CFS con control de cuota de ancho de banda +---------------------------------------------------------------- + +Una vez una "slice" se asigna a una cpu esta no expira. A pesar de eso tod= as, +excepto las "slices" menos las de 1ms, puede ser devueltas a la reserva gl= obal +si todos los hilos en esa cpu pasan a ser no ejecutables. Esto se configura +en el tiempo de compilaci=C3=B3n por la variable min_cfs_rq_runtime. Esto = es un +ajuste en la eficacia que ayuda a prevenir a=C3=B1adir bloqueos en el cand= ado global. + +El hecho de que las "slices" de una cpu local no expiren tiene como result= ado +algunos casos extremos interesantes que debieran ser comprendidos. + +Para una aplicaci=C3=B3n que es un cgroup y que est=C3=A1 limitada en su u= so de cpu +es un punto discutible ya que de forma natural consumir=C3=A1 toda su parte +de cuota as=C3=AD como tambi=C3=A9n la totalidad de su cuota en cpu locale= s en cada +periodo. Como resultado se espera que nr_periods sea aproximadamente igual +a nr_throttled, y que cpuacct.usage se incremente aproximadamente igual +a cfs_quota_us en cada periodo. + +Para aplicaciones que tienen un gran n=C3=BAmero de hilos de ejecuci=C3=B3= n y que no +estan ligadas a una cpu, este matiz de la no-expiraci=C3=B3n permite que l= as +aplicaciones brevemente sobrepasen su cuota l=C3=ADmite en la cantidad que +no ha sido usada en cada cpu en la que el grupo de tareas se est=C3=A1 eje= cutando +(t=C3=ADpicamente como mucho 1ms por cada cpu o lo que se ha definido como +min_cfs_rq_runtime). Este peque=C3=B1o sobreuso =C3=BAnicamente tiene luga= r si +la cuota que ha sido asignada a una cpu y no ha sido completamente usada +o devuelta en periodos anteriores. Esta cantidad de sobreuso no ser=C3=A1 +transferida entre n=C3=BAcleos. Como resultado, este mecanismo todav=C3=AD= a cumplir=C3=A1 +estrictamente los l=C3=ADmites de la tarea de grupo en el promedio del uso, +pero sobre una ventana de tiempo mayor que un =C3=BAnico periodo. Esto +tambi=C3=A9n limita la habilidad de un sobreuso a no m=C3=A1s de 1ms por c= ada cpu. +Esto provee de una experiencia de uso m=C3=A1s predecible para aplicaciones +con muchos hilos y con l=C3=ADmites de cuota peque=C3=B1os en m=C3=A1quina= s con muchos +n=C3=BAcleos. Esto tambi=C3=A9n elimina la propensi=C3=B3n a limitar estas +aplicaciones mientras que simult=C3=A1neamente usan menores cuotas +de uso por cpu. Otra forma de decir esto es que permitiendo que +la parte no usada de una "slice" permanezca v=C3=A1lida entre periodos +disminuye la posibilidad de malgastare cuota que va a expirar en +las reservas de la cpu locales que no necesitan una "slice" completa +de tiempo de ejecuci=C3=B3n de cpu. + +La interacci=C3=B3n entre las aplicaciones ligadas a una CPU y las que no = est=C3=A1n +ligadas a ninguna cpu ha de ser tambi=C3=A9n considerada, especialmente cu= ando +un =C3=BAnico n=C3=BAcleo tiene un uso del 100%. Si se da a cada una de es= as +aplicaciones la mitad de la capacidad de una CPU-n=C3=BAcleo y ambas +est=C3=A1n gestionadas en la misma CPU es te=C3=B3ricamente posible que la= aplicaci=C3=B3n +no ligada a ninguna CPU use su 1ms adicional de cuota en algunos periodos, +y por tanto evite que la aplicaci=C3=B3n ligada a una CPU pueda usar su +cuota completa por esa misma cantidad. En esos caso el algoritmo CFS (vea +sched-design-CFS.rst) el que decida qu=C3=A9 aplicaci=C3=B3n es la elegida= para +ejecutarse, ya que ambas ser=C3=A1n candidatas a ser ejecutadas y tienen +cuota restante. Esta discrepancia en el tiempo de ejecuci=C3=B3n se compen= sar=C3=A1 +en los periodos siguientes cuando el sistema est=C3=A9 inactivo. + +Ejemplos +--------- + +1. Un grupo limitado a 1 CPU de tiempo de ejecuci=C3=B3n. + + Si el periodo son 250ms y la cuota son 250ms el grupo de tareas tendr= =C3=A1 el tiempo + de ejecuci=C3=B3n de 1 CPU cada 250ms:: + + # echo 250000 > cpu.cfs_quota_us /* cuota =3D 250ms */ + # echo 250000 > cpu.cfs_period_us /* periodo =3D 250ms */ + +2. Un grupo limitado al tiempo de ejecuci=C3=B3n de 2 CPUs en una m=C3=A1q= uina varias CPUs. + + Con un periodo de 500ms y una cuota de 1000ms el grupo de tareas tiene= el tiempo + de ejecuci=C3=B3n de 2 CPUs cada 500ms:: + + # echo 1000000 > cpu.cfs_quota_us /* cuota =3D 1000ms */ + # echo 500000 > cpu.cfs_period_us /* periodo =3D 500ms */ + + El periodo m=C3=A1s largo aqu=C3=AD permite una capacidad de r=C3=A1fa= ga mayor. + +3. Un grupo limitado a un 20% de 1 CPU. + + Con un periodo de 50ms, 10ms de cuota son equivalentes al 20% de 1 CPU= s:: + + # echo 10000 > cpu.cfs_quota_us /* cuota =3D 10ms */ + # echo 50000 > cpu.cfs_period_us /* periodo =3D 50ms */ + + Usando un periodo peque=C3=B1o aqu=C3=AD nos aseguramos una respuesta = de + la latencia consistente a expensas de capacidad de r=C3=A1faga. + +4. Un grupo limitado al 40% de 1 CPU, y permite acumular adicionalmente + hasta un 20% de 1 CPU. + + Con un periodo de 50ms, 20ms de cuota son equivalentes al 40% de + 1 CPU. Y 10ms de r=C3=A1faga, son equivalentes a un 20% de 1 CPU:: + + # echo 20000 > cpu.cfs_quota_us /* cuota =3D 20ms */ + # echo 50000 > cpu.cfs_period_us /* periodo =3D 50ms */ + # echo 10000 > cpu.cfs_burst_us /* r=C3=A1faga =3D 10ms */ + + Un ajuste mayor en la capacidad de almacenamiento (no mayor que la cuo= ta) + permite una mayor capacidad de r=C3=A1faga. + base-commit: 77f587896757708780a7e8792efe62939f25a5ab --=20 2.39.2