From nobody Sat Feb 7 11:31:09 2026 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 EB4033EA69; Sat, 10 Aug 2024 10:15:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723284944; cv=none; b=ZeRQ4ynvE9WKzRX/+NpMowXdARoVlIXpRdgj1/usTDlAJIG6XuMPzJiFAdPsrNfJv7gvaRnZ9CWBskVpwGsJZhytwnBrhKuZMUuRC3v+1V618/JblMAZF/hap3M55QBRG/7r2gO+SpWAEqRgS0HxHAC+OQEdYMgkOoaNB1qDm98= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723284944; c=relaxed/simple; bh=0GgeJAjV0gQMUS7xoQJKeK4/4fRBaf7/9vUfHdpslSY=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=ke9+3xlCHuceBPOUvG1P3WkStdUlqffTGUC73Mu4hZqLxnMMAO/Z1E8hBA8dJ8Ugmpendn4HRhoURMIIisXq+aGVHc/7NwXMV4kgkZdM5vOMDO+9SRl4pf9VNoV9BxFCz9zkoV+wjz8g+QykgMlH8yDuVM8UnCxQ2CvbsProzOI= 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=iRX6S7QG; arc=none smtp.client-ip=209.85.221.44 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="iRX6S7QG" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-36dd8a35722so512297f8f.1; Sat, 10 Aug 2024 03:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723284940; x=1723889740; 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=3JdHa3p631wFmGh5Fy5+ZcRKvN82h7bdynK6mL8llGc=; b=iRX6S7QGZzeMQLRDCm+XeKvv/HlA87Hh3P/NYJABgHAgQz0M+7NzQPfIyOHNt2xmC1 sdZc/qxSnjkoJzFYCrl+VboZBh2eHPUPUy44wJm1VK+Mzanoj0v7UsX7YwtYB3sAk9Dv wPkZAz7TwPoARkRztoj85NTX4h3Pcru8QuzU8Fg6h+WqSDpM8EjX9YRB8OA1iTZfLAp6 xJPUcdweP4aSidH+MMlDa0OQ6+D96zgIg3ngdHz8Qd6BWH0NyWm4XMNzDWNRNBKEHMa9 4JC2THct1DGT5L/XHHgTVhU+3v/fICJQyw2pxOKuw2be9ef3+jjhfkOXVcXL/gFmYBQo X9jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723284940; x=1723889740; 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=3JdHa3p631wFmGh5Fy5+ZcRKvN82h7bdynK6mL8llGc=; b=miQmlQL+LPpYYhcJmk2Y151pBMx5+DUpTAZCE05cd/Bo8qyHphKBR2fj1uquUeA3f4 i3NsCYun4l6kuuaD+g2xZ8nP1t7PADErXZZQUFFpxKZeRJjHgRMpTAcvOdR1BOGlx3J3 xKpp1mOz+vw1cjsJcakZmvLNLlhdTdN+kKiLX8B4gcER3iMvpic2JOI3RDJYhuOR1sSR JJPhg/ZTD6aLBy/rNQv2YeWVN5gVcvSYWrTiorBnA/AtETSThHze4h1mGoN5zESJm9DS co3SndtRTiasI2YffDfFodLOcULwmDsDXVKGPq5HsAvQlm0gCVjCLlHc4mIyNe4KIw27 I9KA== X-Forwarded-Encrypted: i=1; AJvYcCWS1NJ+aSrVt8LEKj8LV/qgtCxe3ydZA5avtiPoT/UwyDc+DdwOP4bjuQFJVbZPh9Yeeci0FUR0xuAszMI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz0dCLOEUqPNVC6364MAdHKP4AQs276kLrmOuOG8aELoIsFtX7z Iod6Y28BWrdSVAe6bJBajeIAq59aurQCyQi2hZ1wL5OcwNcxgOqQ X-Google-Smtp-Source: AGHT+IFoEnXnGioMpe8JeLbXDuAdpO8xbuaEpuik291F9hovZxlaCGh0UZ4H6n6iAMNNp8XccJ6Xbg== X-Received: by 2002:adf:f412:0:b0:368:5d2:9e58 with SMTP id ffacd0b85a97d-36d5afac168mr3007894f8f.0.1723284939807; Sat, 10 Aug 2024 03:15:39 -0700 (PDT) Received: from laptop.. (117.red-83-52-251.dynamicip.rima-tde.net. [83.52.251.117]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-36e4ebd3631sm1799227f8f.110.2024.08.10.03.15.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 10 Aug 2024 03:15:38 -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, =?UTF-8?q?Sergio=20Gonz=C3=A1lez=20Collado?= Subject: [PATCH v3] docs/sp_SP: Add translation for scheduler/sched-bwc.rst Date: Sat, 10 Aug 2024 12:15:22 +0200 Message-Id: <20240810101522.15299-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 --- v1 -> v2 typos corrected --- v2 -> v3 typos corrected --- .../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..52b372f8a502 --- /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 = tiempo +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 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-v= 2.rst `. + +- 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. + --=20 2.39.2