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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox