From: "Efraim E. Vander" <efraimvander64@gmail.com>
To: Daniel Pereira <danielmaraboo@gmail.com>,
Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
"Efraim E . Vander" <fraimvander64@gmail.com>,
"Efraim E. Vander" <efraimvander64@gmail.com>
Subject: [PATCH] docs: translations: pt_BR: translate cpu-load.rst
Date: Tue, 13 Oct 2026 12:58:25 +0000 [thread overview]
Message-ID: <20261013125825.3080-1-efraimvander64@gmail.com> (raw)
Translate cpu-load.rst into Brazilian Portuguese and
add it to the pt_BR admin-guide documentation index.
Assisted-by: LLM
Signed-off-by: Efraim E. Vander <efraimvander64@gmail.com>
---
.../pt_BR/admin-guide/cpu-load.rst | 126 +++++++++---------
1 file changed, 65 insertions(+), 61 deletions(-)
diff --git a/Documentation/translations/pt_BR/admin-guide/cpu-load.rst b/Documentation/translations/pt_BR/admin-guide/cpu-load.rst
index 0c76acabe..f0bb48e82 100644
--- a/Documentation/translations/pt_BR/admin-guide/cpu-load.rst
+++ b/Documentation/translations/pt_BR/admin-guide/cpu-load.rst
@@ -1,27 +1,26 @@
-
-
.. SPDX-License-Identifier: GPL-2.0
=============
Carga da CPU
=============
-O Linux exporta diversas informações por meio de `/proc/stat` e `/proc/uptime`, que ferramentas do espaço do usuário (*userland*), como `top(1)`, utilizam para calcular o tempo médio que o sistema passou em determinado estado. Por exemplo:
-
-$ iostat
-Linux 2.6.18.3-exp (linmac) 02/20/2007
+O Linux exporta diversas informações por meio de `/proc/stat` e `/proc/uptime`, que ferramentas do espaço do usuário (*userland*), como `top(1)`, utilizam para calcular o tempo médio que o sistema passou em determinado estado, por exemplo::
-avg-cpu: %user %nice %system %iowait %steal %idle
- 10.01 0.00 2.92 5.44 0.00 81.63
+ $ iostat
+ Linux 2.6.18.3-exp (linmac) 02/20/2007
+ avg-cpu: %user %nice %system %iowait %steal %idle
+ 10.01 0.00 2.92 5.44 0.00 81.63
-Nesse caso, o sistema considera que, durante o período de amostragem padrão, passou 10,01% do tempo executando tarefas no espaço do usuário, 2,92% no kernel e permaneceu ocioso durante 81,63% do tempo total.
+Nesse caso, o sistema considera que, durante o período de amostragem padrão, passou 10,01% do tempo executando tarefas no espaço do usuário, 2,92% no kernel e permaneceu ocioso durante 81,63% do tempo.
-Na maioria dos casos, as informações de `/proc/stat` refletem a realidade com bastante precisão. No entanto, devido à natureza da forma como e do momento em que o kernel coleta esses dados, às vezes essas informações não são confiáveis.
+Na maioria dos casos, as informações de `/proc/stat` refletem a realidade com bastante precisão. No entanto, devido à natureza da forma como e do momento em que os dados são coletados, esses valores podem apresentar imprecisões.
Então, como essas informações são coletadas?
-Sempre que uma interrupção do temporizador (*timer interrupt*) é sinalizada, o kernel verifica que tipo de tarefa estava em execução naquele instante e incrementa o contador correspondente ao tipo ou estado dessa tarefa.
-O problema é que o sistema pode ter alternado entre vários estados diversas vezes entre duas interrupções do temporizador. Ainda assim, o contador é incrementado apenas para o último estado observado.
+
+Sempre que uma interrupção do temporizador (*timer interrupt*) é sinalizada, o kernel verifica que tipo de tarefa estava em execução naquele instante e incrementa o contador correspondente.
+
+O problema é que o sistema pode ter alternado entre vários estados diversas vezes entre duas interrupções do temporizador. Ainda assim, o contador é incrementado apenas uma vez, de acordo com o estado observado no instante da interrupção.
Exemplo
-------
@@ -35,67 +34,72 @@ Imagine um sistema com uma única tarefa que, periodicamente, consome ciclos de
|_ algo começa a trabalhar |_ algo entra em suspensão
(mas é despertado pouco depois)
-
-Na situação acima, de acordo com `/proc/stat`, a carga do sistema será de 0%, pois a interrupção do temporizador sempre ocorrerá quando o sistema estiver executando o tratador de ociosidade (*idle handler*).
+Na situação acima, de acordo com `/proc/stat`, a carga do sistema será de 0%, pois a interrupção do temporizador sempre ocorrerá quando o sistema estiver executando a tarefa ociosa.
Na realidade, porém, a carga estará mais próxima de 99%.
É possível imaginar muitas outras situações em que esse comportamento do kernel pode gerar informações bastante inconsistentes em `/proc/stat`:
- /* gcc -o hog smallhog.c */
-
- #include <time.h>
- #include <limits.h>
- #include <signal.h>
- #include <sys/time.h>
- #define HIST 10
- static volatile sig_atomic_t stop;
+ /* gcc -o hog smallhog.c */
+ #include <time.h>
+ #include <limits.h>
+ #include <signal.h>
+ #include <sys/time.h>
- static void sighandler(int signr)
- {
- (void) signr;
- stop = 1;
- }
+ #define HIST 10
- static unsigned long hog (unsigned long niters)
- {
- stop = 0;
- while (!stop && --niters);
- return niters;
- }
+ static volatile sig_atomic_t stop;
- int main (void)
- {
- int i;
- struct itimerval it = {
- .it_interval = { .tv_sec = 0, .tv_usec = 1 },
- .it_value = { .tv_sec = 0, .tv_usec = 1 } };
- sigset_t set;
- unsigned long v[HIST];
- double tmp = 0.0;
- unsigned long n;
- signal(SIGALRM, &sighandler);
- setitimer(ITIMER_REAL, &it, NULL);
-
- hog (ULONG_MAX);
- for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog(ULONG_MAX);
- for (i = 0; i < HIST; ++i) tmp += v[i];
- tmp /= HIST;
- n = tmp - (tmp / 3.0);
-
- sigemptyset(&set);
- sigaddset(&set, SIGALRM);
-
- for (;;) {
- hog(n);
- sigwait(&set, &i);
- }
- return 0;
- }
+ static void sighandler(int signr)
+ {
+ (void) signr;
+ stop = 1;
+ }
+ static unsigned long hog(unsigned long niters)
+ {
+ stop = 0;
+ while (!stop && --niters);
+ return niters;
+ }
+
+ int main(void)
+ {
+ int i;
+ struct itimerval it = {
+ .it_interval = { .tv_sec = 0, .tv_usec = 1 },
+ .it_value = { .tv_sec = 0, .tv_usec = 1 }
+ };
+ sigset_t set;
+ unsigned long v[HIST];
+ double tmp = 0.0;
+ unsigned long n;
+
+ signal(SIGALRM, &sighandler);
+ setitimer(ITIMER_REAL, &it, NULL);
+
+ hog(ULONG_MAX);
+ for (i = 0; i < HIST; ++i)
+ v[i] = ULONG_MAX - hog(ULONG_MAX);
+
+ for (i = 0; i < HIST; ++i)
+ tmp += v[i];
+
+ tmp /= HIST;
+ n = tmp - (tmp / 3.0);
+
+ sigemptyset(&set);
+ sigaddset(&set, SIGALRM);
+
+ for (;;) {
+ hog(n);
+ sigwait(&set, &i);
+ }
+ return 0;
+ }
Referências
-----------
--
2.43.0
next reply other threads:[~2026-10-13 12:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 12:58 Efraim E. Vander [this message]
2026-10-13 14:40 ` [PATCH] docs: translations: pt_BR: translate cpu-load.rst Daniel Pereira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261013125825.3080-1-efraimvander64@gmail.com \
--to=efraimvander64@gmail.com \
--cc=corbet@lwn.net \
--cc=danielmaraboo@gmail.com \
--cc=fraimvander64@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.