Power management (Português) - ArchWiki

Jump to content
From ArchWiki
Status de tradução: Esse artigo é uma tradução de Power Management. Data da última tradução: 2023-10-01. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Artigos relacionados

- Gestão de energia/Suspensão e hibernação
- Power management/Wakeup triggers
- Display Power Management Signaling
- Escala de frequência do CPU
- Hybrid graphics
- Módulos de kernel
- sysctl
- udev

Gestão de energia, ou gerenciamento de energia, é um recurso que desliga ou troca o comportamento dos componentes do sistema para um estado de economia de energia quando inativo.

Em Arch Linux, a gestão de energia consiste em duas partes principais:

1. Configuração do kernel Linux, que interage com o hardware:
   - Parâmetros de kernel
   - Módulos de kernel
   - Regras udev
2. Configuração de ferramentas do espaço de usuário (userspace), que interage com o kernel e reage aos respectivos eventos. Muitas destas ferramentas permitem modificar a configuração de kernel em um ambiente amigável, ou também chamado de user-friendly, para facilitar o gerenciamento por um usuário padrão. Veja as opções logo abaixo.

## Ferramentas do espaço de usuário (userspace)

Usar estas ferramentas podem substituir a definição de muitas configurações a mão. Apenas escolha uma delas para evitar possíveis conflitos, pois todas funcionam de maneira similar. Visite as categorias listadas em inglês e dê uma olhada em um plano geral quais opções para gestão de energia existem em Arch Linux.

A seguir estão listados os scripts desenvolvidos e as ferramentas projetadas mais populares para ajudar na gestão de energia:

### Console

- acpid — Um daemon que entrega gerenciamento energético em eventos ACPI com suporte a netlink.

  https://sourceforge.net/projects/acpid2/ || acpid

- Laptop Mode Tools — Utilitário para definir a economia de energia em notebooks/laptops. Considerado por muitos a mais efetiva para gestão de energia, apesar de requerer um pouco de configuração.

  https://github.com/rickysarraf/laptop-mode-tools || laptop-mode-toolsAUR

- libsmbios — Conjunto de bibliotecas e ferramentas para interagir com tabelas Dell SMBIOS.

  https://github.com/dell/libsmbios || libsmbios

- powertop — Uma ferramenta para diagnosticar problemas com o consumo e gestão de energia e ajudar a configurar a economia de energia.

  https://github.com/fenrus75/powertop || powertop

- systemd — Um gerenciador de sistema e de serviço.

  https://freedesktop.org/wiki/Software/systemd/ || systemd

- TLP — Gestão de energia avançada para sistemas Linux.

  https://linrunner.de/tlp || tlp

### Gráfico

- batsignal — Monitor de bateria leve que usa libnotify para alertar os níveis baixos de bateria.

  https://github.com/electrickite/batsignal || batsignalAUR

- cbatticon — Ícone rápido e leve que permanece na bandeja do sistema.

  https://github.com/valr/cbatticon || cbatticon

- GNOME Power Statistics — Exibe para o GNOME informações e estatísticas do uso de energia do sistema.

  https://gitlab.gnome.org/GNOME/gnome-power-manager || gnome-power-manager

- KDE Power Devil — Módulo de gestão de energia para o Plasma.

  https://invent.kde.org/plasma/powerdevil || powerdevil

- LXQt Power Management — Módulo de gestão de energia para o LXQt.

  https://github.com/lxqt/lxqt-powermanagement || lxqt-powermanagement

- MATE Power Management — Módulo de gestão de energia para o MATE.

  https://github.com/mate-desktop/mate-power-manager || mate-power-manager

- MATE Power Statistics — Exibe para o MATE informações e estatísticas do uso de energia do sistema.

  https://github.com/mate-desktop/mate-power-manager || mate-power-manager

- poweralertd — Daemon de entrega de notificações do UPower.

  https://git.sr.ht/~kennylevinsen/poweralertd || poweralertdAUR

- powerkit — Gestor de energia desktop independente.

  https://github.com/rodlie/powerkit || powerkitAUR

- Xfce Power Manager — Gestor de energia para o Xfce.

  https://docs.xfce.org/xfce/xfce4-power-manager/start || xfce4-power-manager

- vattery — Applicativo de monitoramento da bateria escrito em Vala que exibe status de bateria em notebooks/laptops na bandeja do sistema.

  https://www.jezra.net/projects/vattery.html || vatteryAUR

## Gestão de energia

### Eventos ACPI

O systemd gerencia alguns eventos ACPI relacionados à energia, tais ações de eventos podem ser configuradas em `/etc/systemd/logind.conf` ou `/etc/systemd/logind.conf.d/*.conf` — veja em logind.conf(5). Normalmente o daemon acpid é usado somente com o propósito de reagir aos eventos ACPI, e em função disso, em sistemas sem gestor de energia dedicado é comum que o systemd faça a substituição do acpid.

A ação especificada para cada evento pode ser uma das seguintes opções: `ignore`, `poweroff`, `reboot`, `halt`, `suspend`, `hibernate`, `hybrid-sleep`, `suspend-then-hibernate`, `lock` ou `kexec`; respectivamente as opções significam "ignorar", "desligar", "reiniciar", "interromper/descontinuar", "suspender", "hibernar", "suspensão híbrida" "suspender então hibernar", "bloquear" e "kexec". Em caso de hibernação e suspensão garanta que as configurações sejam apropriadamente definidas, se caso não configurado o systemd usará as ações de evento padronizadas.

Manipulador de evento | Descrição de como acionar o evento | Ação padrão
--- | --- | ---
`HandlePowerKey` | Tecla/botão de energia (power on/off) é pressionado. | `poweroff`
`HandleSuspendKey` | Tecla/botão de suspensão é pressionado. | `suspend`
`HandleHibernateKey` | Tecla/botão de hibernação é pressionado. | `hibernate`
`HandleLidSwitch` | A tampa é fechada, exceto nos casos abaixo. | `suspend`
`HandleLidSwitchDocked` | A tampa é fechada enquanto o sistema está inserido em um dock station (régua de recarga), ou quando mais de um display está conectado. | `ignore`
`HandleLidSwitchExternalPower` | A tampa é fechada enquanto o sistema está conectado a uma fonte externa de energia. | A ação é definida por: `HandleLidSwitch`

Para aplicar qualquer mudança, mande um sinal para `systemd-logind` com `HUP`:

    # systemctl kill -s HUP systemd-logind

Nota: Systemd não pode modificar eventos ACPI de carregamento e bateria, portanto se você usa Laptop Mode Tools ou outras ferramentas similares o acpid ainda é requisito.

#### Gestores de energia

Alguns ambientes de desktop incluem gestores de energia que inibem (temporariamente desligam) algumas ou todas as configurações ACPI do systemd. Se tais gestores de energia estão ativos, então as ações dos eventos ACPI podem ser configuradas nestes gestores de energia por si só. Modificações em `/etc/systemd/logind.conf` ou `/etc/systemd/logind.conf.d/*.conf` precisam ser feitas somente se o comportamento desejado para um evento em particular não estiver restrito pelo gerenciador de energia.

Note que se o gestor de energia não inibe apropriadamente os eventos do systemd, você pode acabar em uma situação complicada, cujo systemd suspende o sistema e quando acordado o outro gerenciador de energia o suspende de volta. Os gestores de energia de KDE Plasma, GNOME, Xfce e MATE proporcionam os comandos necessários já inibidos. Se os comandos inibidos não estão funcionando, como por exemplo sob uso do acpid ou outros manipuladores de eventos ACPI, defina a opção `Handle` para `ignore` no systemd. Veja também sobre em systemd-inhibit(1).

#### xss-lock

xss-lock subscreve em `systemd-events` as opções `suspend`, `hibernate`, `lock-session` e `unlock-session`; respectivamente os termos significam "suspender", "hibernar", "bloquear sessão" e "desbloquear sessão". As opções são usadas para definir as ações apropriadas de cada evento, para tal é só executar o bloqueio e esperar o usuário desbloquear ou matar o processo. O xss-lock também reage com eventos DPMS e consegue executar ou matar o bloqueio em resposta.

Autoinicie o programa usando algo como o exemplo abaixo:

    $ xss-lock -- i3lock -n -i background_image.png &

### Suspensão e hibernação

O systemd fornece comandos de suspensão para a RAM ou hibernação para o disco com a funcionalidade suspensão/retorno nativa do kernel. Há também mecanismos que adicionam hooks para personalizar ações pré e pós suspensão.

A suspensão com `systemctl suspend` normalmente já vem funcionando pronta para o uso, por outro lado a hibernação com `systemctl hibernate` precisa que instruções específicas sejam seguidas; veja a página Suspender e hibernar#Hibernação.

Há também dois modos que integram suspensão e hibernação:

- Suspensão híbrida: `systemctl hybrid-sleep` suspende o sistema com o uso de RAM e o uso de disco, portanto uma queda de energia não resulta em perda de dados. Esse modo também é chamado de suspender para ambos (ou sono híbrido).
- Suspender então hibernar: `systemctl suspend-then-hibernate` inicialmente suspende o sistema para RAM pelo tempo mais longo possível, então o sistema é acordado com um alarme RTC (relógio em tempo real) e hiberna. O alarme RTC é definido pelo `HibernateDelaySec` em systemd-sleep.conf(5). O valor padrão é programado de acordo com uma medida aproximada do descarregamento da bateria para manter o sistema com no mínimo 5% de bateria, ou com até 2 horas sem fonte de carga. A estimativa é obtida de acordo com a mudança de nível da bateria após um tempo especificado pelo `SuspendEstimationSec` no arquivo systemd-sleep.conf(5), para isso o sistema acordará brevemente e calculará uma estimativa (a medição também é feita se o sistema for acordado manualmente da suspensão).

Nota: O systemd pode também usar outros backends de suspensão (como Uswsusp), como forma de adição ao backend de kernel padrão, ao fim de alterar o estado do computador para dormir ou hibernar. Veja a seção Uswsusp#Com systemd para um exemplo prático.

#### Suspensão híbrida quando requisitado suspensão ou hibernação

É possível configurar o systemd para sempre fazer hybrid-sleep (suspensão híbrida) mesmo que suspend (suspensão) ou hibernation (hibernação) sejam requisitados.

A ação padrão de suspend e hibernation podem ser configuradas via arquivos .conf em `/etc/systemd/sleep.conf.d/`. Para definir que ambas as ações resultem em sono híbrido:

    /etc/systemd/sleep.conf.d/hybrid-sleep.conf

    [Sleep]
    # suspender = suspensão híbrida
    SuspendMode=suspend
    SuspendState=disk
    # hibernar = suspensão híbrida
    HibernateMode=suspend
    HibernateState=disk

Veja o manual sleep.conf.d(5) e a documentação de estados de energia do kernel Linux para mais detalhes.

#### Desabilitar suspensão

Quando usado um dispositivo em um servidor, por exemplo, suspender pode não ser necessário ou é inviável. Qualquer estado de sono pode ser desativado da seguinte forma:

    /etc/systemd/sleep.conf.d/disable-suspend.conf

    [Sleep]
    AllowSuspend=no
    AllowHibernation=no
    AllowSuspendThenHibernate=no
    AllowHybridSleep=no

### Hooks de sono

#### Arquivos de serviço de suspensão/retorno

Arquivos de serviço podem usar hooks dentro de suspend.target, hibernate.target, sleep.target, hybrid-sleep.target e suspend-then-hibernate.target; respectivamente correspondem a "suspender", "hibernar", "dormir", "suspensão híbrida" e "suspender então hibernar". Todos os targets listados podem executar ações antes ou depois de suspensão/hibernação; devem ser criados arquivos separados para definir ações de usuários e ações de root/sistema. Ative os serviços `suspend@user` e `resume@user` ao fim de ambos iniciarem durante o boot. Exemplos:

    /etc/systemd/system/suspend@.service

    [Unit]
    Description="Descrição de ações de suspensão do usuário"
    Before=sleep.target

    [Service]
    User=%I
    Type=forking
    Environment=DISPLAY=:0
    ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop
    ExecStart=/usr/bin/sflock
    ExecStartPost=/usr/bin/sleep 1

    [Install]
    WantedBy=sleep.target

    /etc/systemd/system/resume@.service

    [Unit]
    Description="Descrição de ações de retorno do usuário"
    After=suspend.target

    [Service]
    User=%I
    Type=simple
    ExecStart=/usr/local/bin/ssh-connect.sh

    [Install]
    WantedBy=suspend.target

Nota: Como os bloqueadores de tela podem retornar antes da tela estar "bloqueada", a tela pode piscar ao retornar da suspensão. Adicionar um pequeno tempo de espera via `ExecStartPost=/usr/bin/sleep 1` previne que isto ocorra.

Para ações de root/sistema (ative os serviços `root-resume` e `root-suspend` ao fim de ambos iniciarem durante o boot):

    /etc/systemd/system/root-suspend.service

    [Unit]
    Description="Ações de suspensão do sistema local"
    Before=sleep.target

    [Service]
    Type=simple
    ExecStart=-/usr/bin/pkill sshfs

    [Install]
    WantedBy=sleep.target

    /etc/systemd/system/root-resume.service

    [Unit]
    Description="Ações de retorno do sistema local"
    After=suspend.target

    [Service]
    Type=simple
    ExecStart=/usr/bin/systemctl restart mnt-media.automount

    [Install]
    WantedBy=suspend.target

Dica: Logo abaixo há algumas sugestões para lhe dar uma mão (e ainda há mais em systemd.service(5)):

- Se o parâmetro for `Type=oneshot`, então você pode usar múltiplas linhas de `ExecStart=`. Caso contrário apenas uma linha `ExecStart` é permitida. Você pode adicionar vários comandos tanto com `ExecStartPre` quanto pela separação por ponto e vírgula de comandos em série. Veja o primeiro exemplo demonstrado acima, perceba os espaços antes e depois da pontuação como se fosse requisito.
- Um comando escrito com `-` (hífen) como prefixo fará uma saída diferente de zero ser totalmente ignorada, ou seja, mesmo que resulte em erro será tratado como um comando bem sucedido.
- Claramente o melhor lugar para encontrar erros ao fazer troubleshooting destes arquivos de serviço é com journalctl.

#### Arquivo de serviço com suspensão/retorno agregado

Um único hook faz todo o trabalho para diferentes fases (dormir/retorno) e para diferentes targets (suspender/hibernar/suspensão híbrida) com a junção de suspensão/retorno em um arquivo de serviço.

Exemplo e explicação:

    /etc/systemd/system/wicd-sleep.service

    [Unit]
    Description="Hook de sono Wicd"
    Before=sleep.target
    StopWhenUnneeded=yes

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=-/usr/share/wicd/daemon/suspend.py
    ExecStop=-/usr/share/wicd/daemon/autoconnect.py

    [Install]
    WantedBy=sleep.target

- `RemainAfterExit=yes`: Logo que iniciado o serviço é considerado ativo até que seja explicitamente pedido o encerramento. O termo significa "Continuar-Depois-de-Saída".
- `StopWhenUnneeded=yes`: O serviço ativo será parado se nenhum outro serviço ativo necessitar dele. No exemplo acima em específico, o mesmo será finalizado depois que sleep.target parar. O termo significa "Parar-Quando-Desnecessário".
- Por conta de sleep.target ser puxado pelos suspend.target, hibernate.target e hybrid-sleep.target, além do fato que o próprio sleep.target é um serviço StopWhenUnneeded, é garantido que o hook inicie/pare apropriadamente para diferentes tarefas.

##### Template genérico de serviço

Neste exemplo nós criamos um template de serviço, do qual pode ser conectado, ou no caso ser criado um hook, em qualquer serviço do systemd existente aos eventos de energia:[1]

    /etc/systemd/system/sleep@.service

    [Unit]
    Description="Hook de sono %I"
    Before=sleep.target
    StopWhenUnneeded=yes

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=-/usr/bin/systemctl stop %i
    ExecStop=-/usr/bin/systemctl start %i

    [Install]
    WantedBy=sleep.target

Depois ative uma instância deste template ao especificar o nome base de um serviço systemd existente logo após o `@`, isto é: `sleep@service-file-basename.service`. Veja systemd.unit(5) § DESCRIPTION para mais detalhes sobre templates.

Dica: Templates não são limitados aos serviços do systemd e podem ser usados com outros programas. Veja outros exemplos em [2].

#### Hooks em /usr/lib/systemd/system-sleep

O systemd inicia todos os executáveis em `/usr/lib/systemd/system-sleep/` e passa dois argumentos para cada um deles:

- Argumento 1: tanto `pre` quanto `post`, depende de quando a máquina irá dormir ou acordar.
- Argumento 2: `suspend`, `hibernate` ou `hybrid-sleep`, depende do que está sendo chamado.

Systemd executará esses scripts simultaneamente, não um atrás do outro.

A saída de qualquer script personalizado terá seu registro por log em systemd-suspend.service, systemd-hibernate.service ou systemd-hybrid-sleep.service. Você pode ver o resultado da saída em journalctl:

    # journalctl -b -u systemd-suspend.service

Nota: É também possível usar sleep.target, suspend.target, hibernate.target ou hybrid-sleep.target para conectar units (hook units) dentro da lógica de estado do sono ao invés de usar scripts personalizados.

Um exemplo de um script personalizado para o sono seria:

    /usr/lib/systemd/system-sleep/example.sh

    #!/bin/sh
    case $1/$2 in
      pre/*)
        echo "Going to $2..."
        ;;
      post/*)
        echo "Waking up from $2..."
        ;;
    esac

Lembre-se de marcar o script como executável.

Veja systemd.special(7) e systemd-sleep(8) para mais detalhes.

### Solução de problemas

#### Ação de lid switch lenta

Quando aberta/fechada sucessivamente a tampa em um curto período de tempo, o logind aumenta o tempo de suspensão em até 90 segundos, com o intuito de detectar docks [3]. O tempo de espera é alterável desde a versão 220 do systemd [4]. O exemplo a seguir demonstra como mudar em até 30 segundos a espera:

    /etc/systemd/logind.conf

    ...
    HoldoffTimeoutSec=30s
    ...

#### Combinações com a tecla Fn não acionam suspensão

Se apesar de configurado não funcionar o botão para acionar o evento de sono em logind.conf, e nem mesmo ao pressionar é emitido mensagens em syslog, então provavelmente logind não está monitorando o teclado [5]. Para resolver use:

    # journalctl --grep="Watching system buttons"

Você provavelmente verá algo parecido com:

    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)
    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)
    May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)

Note que não há nenhum dispositivo de teclado sendo monitorado. Liste os dispositivos de teclado com:

     # stat -c%N /dev/input/by-id/*-kbd

    ...
    /dev/input/by-id/usb-SIGMACHIP_USB_Keyboard-event-kbd -> ../event6
    ...

Agora obtenha o `ATTRS{name}`, parte do dispositivo pai do teclado [6]. Como um exemplo, na listagem acima o dispositivo está com o evento da entrada como `/event6`, o mesmo pode ser usado para buscar o nome do respectivo atributo:

    # udevadm info -a /dev/input/event6

    ...
    KERNEL=="event6"
    ...
    ATTRS{name}=="SIGMACHIP USB Keyboard"

Escreva uma regra personalizada para adicionar a tag "power-switch":

    /etc/udev/rules.d/70-power-switch-my.rules

    ACTION=="remove", GOTO="power_switch_my_end"
    SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="SIGMACHIP USB Keyboard", TAG+="power-switch"
    LABEL="power_switch_my_end"

Reinicie `systemd-udevd.service`, atualize as regras executando `udevadm trigger` como root e reinicie `systemd-logind.service`.

Agora você deve ver em syslog o evento sendo monitorado: `Watching system buttons on /dev/input/event6`.

#### Computador não acorda do sono em placas-mãe A520I e B550I

Em placas-mãe com chipsets A520i e B550i, o sistema não irá adentrar completamente no estado de sono ou sequer retornar. Sintomas incluem o sistema entrar no sono e o monitor desligar enquanto LEDs internos da placa-mãe ou LED do botão power continuam acessos. Consequentemente o sistema não irá conseguir trocar de estado e requer desligamento forçado. Se você estiver com um problema similar na AMD, primeiro tenha certeza que seu sistema está totalmente atualizado e verifique se o pacote microcode da AMD está instalado.

Verifique se a linha que começa com `GPP0` possui o status ativo (enabled):

    $ cat /proc/acpi/wakeup

    Device	S-state	  Status   Sysfs node
    GP12	  S4	*enabled   pci:0000:00:07.1
    GP13	  S4	*enabled   pci:0000:00:08.1
    XHC0	  S4	*enabled   pci:0000:0b:00.3
    GP30	  S4	*disabled
    GP31	  S4	*disabled
    PS2K	  S3	*disabled
    GPP0	  S4	*enabled   pci:0000:00:01.1
    GPP8	  S4	*enabled   pci:0000:00:03.1
    PTXH	  S4	*enabled   pci:0000:05:00.0
    PT20	  S4	*disabled
    PT24	  S4	*disabled
    PT26	  S4	*disabled
    PT27	  S4	*disabled
    PT28	  S4	*enabled   pci:0000:06:08.0
    PT29	  S4	*enabled   pci:0000:06:09.0

Se estiver ativado, você pode executar o comando abaixo:

    # echo GPP0 > /proc/acpi/wakeup

Agora teste com `systemctl suspend` e deixe o sistema dormir. Depois de alguns segundos acorde o sistema. Se funcionou, você pode deixar o ajuste permanente ao criar um arquivo unit do systemd:

    /etc/systemd/system/aciona-gpp0-para-corrigir-retorno.service

    [Unit]
    Description="Desabilita GPP0 para resolver problema de suspensão"

    [Service]
    ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"

    [Install]
    WantedBy=multi-user.target

Faça systemd daemon-reload e inicie/habilite a unit recém criada.

### Dicas e truques

#### Swap apenas para hibernação sob demanda

Em algumas configurações talvez seja preferível ter uma área de swap ativada somente para hibernação e desativada novamente quando for retornar do sono.

Enquanto que o efeito pode ser alcançado via hooks, descrito em uma das seções acima, é também possível usar diretamente uma configuração de swap unit (veja systemd.swap(5)), feito da seguinte maneira ou semelhante:

    /etc/systemd/system/caminho-para-swap.swap

    [Unit]
    Before=systemd-hibernate.service
    StopWhenUnneeded=true

    [Swap]
    What=/caminho/para/swap
    Options=noauto

    [Install]
    RequiredBy=systemd-hibernate.service

Nota:

- O nome do arquivo unit deve corresponder ao nome do caminho (pathname) do respectivo dispositivo de swap (ou arquivo) e é indispensável ativar a unit para que `RequiredBy=` tenha efeito.
- É também possível depender de `hibernate.target` ao invés de `systemd-hibernate.service`, porém usar diretamente o comando `systemctl start systemd-hibernate.service` pode não funcionar.
- Ambientes de desktop podem não mostrar a opção para hibernação e `systemctl hibernate` não irá funcionar, pelo fato que tais ambientes solicitam (query) `systemd-logind` para modos de economia de energia disponíveis, e não haverá como anunciar hibernação, a não ser que exista uma área de swap ativada. Isto pode ser contornado iniciando `systemd-logind` com o valor `SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1` na variável de ambiente, por exemplo via um arquivo drop-in como:

    /etc/systemd/system/systemd-logind.service.d/desativar-checagem-de-swap-para-hibernar.conf

    [Service]
    Environment="SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1"

## Economia de energia

Note: Veja Laptop (Português)#Gerenciar energia para um guia mais especifico de gerenciamento de energia para notebooks/laptops, tal como monitoramento de bateria. Veja também as páginas específicas para a sua CPU e GPU (por exemplo Ryzen, AMDGPU, etc).

Esta seção é uma referência para criar scripts customizados e configurações de economia de energia, bem como por regras udev. Antes tenha certeza que as definições não estão a ser gerenciadas por outro utilitário para evitar conflitos.

Praticamente todas as funcionalidades listadas aqui merecem o uso mesmo que o computador esteja conectado diretamente a uma fonte de alimentação ou pela bateria. Muitos tem impacto de performance negligenciável e só não são habilitados por padrão porque é comum a quebra de hardware/drivers. Reduzir o gasto de energia significa diminuir o calor, logo isso gera maior desempenho de um processador Intel ou AMD moderno, graças ao overclocking dinâmico.

### Processadores com suporte Intel HWP (Intel Hardware P-state)

As preferências de energia disponíveis de um processador com suporte HWP são `default`, `performance`, `balance_performance`, `balance_power` e `power`; respectivamente "padrão/normal", "desempenho", "desempenho balanceado", "economia de energia balanceada" e "economia de energia" (os dois últimos termos definem uma maior eficiência energética).

As opções válidas do sistema podem ser vistas da seguinte forma:

    $ cat /sys/devices/system/cpu/cpufreq/policy*/energy_performance_available_preferences

Para reduzir o gasto energético, você pode criar uma configuração com o seguinte arquivo:

    /etc/tmpfiles.d/energy_performance_preference.conf

    w /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference - - - - balance_power

Veja o manual x86_energy_perf_policy(8) para consultar mais detalhes sobre o protocolo de desempenho energético da Intel. Consulte igualmente os manuais systemd-tmpfiles(8) e tmpfiles.d(5) para mais detalhes sobre arquivos/diretórios temporários.

### Áudio

#### Kernel

Por padrão, economia de energia do áudio é desabilitada em vários drivers. Pode ser habilitada ao definir o parâmetro `power_save`; um tempo (em segundos) deixa o dispositivo em modo ocioso. Para manter a placa de áudio ociosa após um segundo, crie o seguinte arquivo para placas de som Intel:

    /etc/modprobe.d/audio_powersave.conf

    options snd_hda_intel power_save=1

Alternativamente, defina a opção a seguir para ac97:

    options snd_ac97_codec power_save=1

Nota:

- Para recuperar fabricante e driver de kernel correspondentes a placa de áudio, execute `lspci -k`.
- Acionar o estado de economia de energia na placa de áudio pode causar som de estouro/estalo ou latência perceptível em alguns hardwares quebrados.

Da mesma forma é possível reduzir ainda mais os requerimentos de energia ao desabilitar a saída de áudio HDMI, que pode ser feito ao criar uma lista negra dos módulos de kernel apropriados (por exemplo com `snd_hda_codec_hdmi` em caso de hardware Intel).

#### PulseAudio

Por padrão, PulseAudio suspende qualquer fonte de áudio que se tornou ociosa por muito tempo. Quando usado um microfone externo USB, gravações podem começar com um som de estouro/estalo. Para contornar a situação comente na seguinte linha em `/etc/pulse/default.pa`:

    load-module module-suspend-on-idle

Logo após feito, reinicie o PulseAudio com `systemctl restart --user pulseaudio`.

### Retroiluminação - Backlight

Veja a página em inglês sobre Backlight.

### Bluetooth

Para desativar completamente o bluetooth crie uma lista negra com os módulos `btusb` e `bluetooth`.

Desligue apenas temporariamente o bluetooth por rfkill:

    # rfkill block bluetooth

Ou por regra udev:

    /etc/udev/rules.d/50-bluetooth.rules

    # Desabilitar bluetooth
    SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"

### Webcam

Se você não irá usar uma webcam integrada, então crie uma lista negra para bloquear o módulo `uvcvideo`.

### Parâmetros de kernel

Esta seção visa o uso de configurações em `/etc/sysctl.d/`, que significa usar "um diretório drop-in para os parâmetros sysctl de kernel." Veja mais em Os novos arquivos de configuração e mais especificamente no manual em sysctl.d(5).

#### Desativar NMI do watchdog

This article or section needs expansion.

Reason: Esta seção ou sobre `nowatchdog` é o mesmo visto em Melhorando o desempenho#Watchdogs (Discuss in talk:Power management)

O NMI do watchdog é um recurso de debugging (depuração) para capturar travamentos de hardware que causam pânico no kernel. Em alguns sistemas isto pode gerar várias interrupções, consequentemente é notável um aumento no consumo de energia. Use:

    /etc/sysctl.d/disable_watchdog.conf

    kernel.nmi_watchdog = 0

Ou adicione `nmi_watchdog=0` em uma linha de comando do kernel para desativá-lo completamente desde o início de boot.

#### Tempo de resposta da escrita (writeback)

Aumentar tempo de writeback da memória virtual suja ajuda a agregar o conjunto das E/S (I/O) do disco, e portanto reduz a duração de escritas pelo disco e aumenta a economia de energia. Para definir o valor em 60 segundos (o padrão é 5 secs):

    /etc/sysctl.d/dirty.conf

    vm.dirty_writeback_centisecs = 6000

Para fazer o mesmo com a alocação de registro (journal commits) nos sistemas de arquivos suportados (por exemplo ext4, btrfs...), use a opção `commit=60` em fstab.

Note que este valor é modificado como um efeito colateral das configurações do modo notebook/laptop, descrito na seção abaixo. Veja também sobre outros parâmetros que afetam a performance de E/S (I/O) e a economia de energia em sysctl#Virtual memory.

#### Modo notebook/laptop

Veja sobre O valor sensível de "knob" em 5 segundos - modo laptop na documentação do kernel para mais detalhes sobre a configuração a seguir:

    /etc/sysctl.d/laptop.conf

    vm.laptop_mode = 5

Nota: Esta definição é especialmente relevante para discos giratórios (HDDs).

### Interfaces de rede

O Wake-on-LAN pode ser um recurso muito útil, porém se não for usado o efeito é a drenagem extra de energia a espera de um pacote mágico enquanto o sistema é suspenso. Você pode adaptar a regra udev para desabilitar o recurso em todas as interfaces de Ethernet. Para habilitar a economia de energia com o uso de iw em todas as interfaces sem fio:

    /etc/udev/rules.d/81-wifi-powersave.rules

    ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"

O nome para o arquivo de configuração é importante, com o uso de nomes de dispositivos persistentes em systemd, a regra de rede acima, chamada pela lexicografia derivada de `80-net-setup-link.rules`, é aplicada após o dispositivo ser renomeado com um nome persistente, por exemplo `wlan0` é renomeado como `wlp3s0`. Esteja ciente que o comando `RUN` é executado depois que todas as regras foram processadas e as mesmas devem usar o nome persistente, disponível em `$name` e do qual corresponde a um determinado dispositivo.

#### Placas de internet sem fio da Intel (iwlwifi)

Funções de economia de energia adicionais com o driver `iwlwifi` das placas de internet sem fio da Intel podem ser ativadas ao passar os parâmetros corretos ao módulo de kernel, além de serem modificações persistentes ao incrementar as linhas abaixo para o arquivo `/etc/modprobe.d/iwlwifi.conf`:

    options iwlwifi power_save=1

Esta opção provavelmente aumentará a latência média:

    options iwlwifi uapsd_disable=0

Em kernels < 5.4 (abaixo da versão 5.4) você até pode usar a opção abaixo, mas é provável que diminua o processamento máximo da placa:

    options iwlwifi d0i3_disable=0

Dependendo da sua placa de internet sem fio um dos módulos abaixo será aplicável:

    options iwlmvm power_scheme=3

    options iwldvm force_cam=0

Você pode verificar qual deles é relevante ao investigar qual destes módulos está sendo usado com:

    # lsmod | grep '^iwl.vm'

Tenha em mente que essas opções de economia de energia são experimentais e podem causar instabilidade no sistema.

### Gerenciamento de energia em Bus

#### Gestão de energia de estado ativo

Trecho traduzido e retirado da Wikipédia:

  Active-state power management (ASPM) é o mecanismo de gestão de energia para dispositivos PCI Express adquirirem economia de energia, apesar de estarem em um estado ativo de uso. Predominantemente, isto é alcançado através da conexão do gerenciamento de energia com o estado ativo, ou seja, o vínculo de serial (PCI Express serial) é desligado quando não há nenhum tráfego de dados sendo passado. Normalmente isto é usado em notebooks/laptops e outros dispositivos móveis com internet para estender a vida da bateria.

No boot a BIOS ativa ou desativa o uso de ASPM baseado no suporte do hardware disponível. Para verificar o suporte:

    # lspci -vv | grep 'ASPM.*abled;'

Busque por protocolos disponíveis e o padrão atual do sistema com:

    $ cat /sys/module/pcie_aspm/parameters/policy

    [default] performance powersave powersupersave

ASPM pode estar desabilitado pelas seguintes razões [7]:

1. A BIOS desabilitou por algum motivo (talvez por conflitos?).
2. PCIE requer ASPM, mas L0s são opcionais (então L0s pode estar desativado e somente L1 está ativado).
3. A BIOS pode não ter sido programada para isto ou estar bugada.

Se você acredita que seu hardware possui o suporte para ASPM, apesar do que foi listado acima, existe a alternativa de forçar a ativação para o kernel administrar com a opção `pcie_aspm=force` definida nos parâmetros de kernel.

Atenção:

- Forçar a ativação de ASPM em um sistema sem suporte pode na realidade aumentar o consumo de energia. A longo prazo pode causar congelamentos ou pânicos de kernel no sistema, portanto tenha certeza que você tem um jeito de refazer a opção se ela estiver sendo inconveniente.
- Embora o ASPM tenha sido imposto a força para tomar lugar no funcionamento do kernel, há uma chance de não dar certo e continuar desabilitado no hardware. Para verificar se esse é o caso, execute `dmesg | grep ASPM` como root. Consulte se possível o artigo específico do seu hardware na Wiki para mais informações.

Contanto que ASPM seja suportado e ativado, é possível selecionar o protocolo desejado para a sessão atual. Por exemplo, a troca de `powersupersave` para a sessão atual é feita com uso de:

    # echo powersave > /sys/module/pcie_aspm/parameters/policy

Para configurar a ativação de um estado especifico de ASPM a partir do boot do sistema (usando `powersupersave`, por exemplo), adicione `pcie_aspm.policy=powersupersave` como um parâmetro de kernel.

#### Gestão de energia do tempo de execução PCI (PCI runtime)

    /etc/udev/rules.d/pci_pm.rules

    SUBSYSTEM=="pci", ATTR{power/control}="auto"

A regra acima desliga todos os dispositivos em desuso, porém alguns destes dispositivos não poderão acordar. Para permitir somente a gestão de energia do tempo de execução de dispositivos que são conhecidos por operar normalmente, faça uma combinação simples entre vendor e device IDs (use `lspci -nn` para pegar estes valores):

    /etc/udev/rules.d/pci_pm.rules

    # lista branca para autossuspensão pci
    SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"

Como segunda opção, coloque na lista negra dispositivos não operantes com a gestão de energia do tempo de execução PCI e mantenha ativo para todos os outros hardwares:

    /etc/udev/rules.d/pci_pm.rules

    # lista negra para a gestão de energia do tempo de execução pci
    SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"

    SUBSYSTEM=="pci", ATTR{power/control}="auto"
    LABEL="pci_pm_end"

#### Autossuspensão USB

O kernel Linux pode automaticamente suspender dispositivos USB quando não estão sendo usados. Às vezes a prática traz uma pequena economia de energia, porém alguns dispositivos USB não são compatíveis com a economia de energia USB e começam a mudar de comportamento (comum em teclados e microfones USB). Regras udev baseadas na filtragem por lista branca ou lista negra ajudam a mitigar o problema.

O mais simples exemplo, entretanto um pouco inútil, é ativando a autossuspensão para todos os dispositivos USB:

    /etc/udev/rules.d/50-usb_power_save.rules

    ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"

Para permitir a autossuspensão de somente alguns dispositivos com o funcionamento conhecido, simplesmente busque a combinação entre vendor e product IDs (use lsusb para pegar estes valores):

    /etc/udev/rules.d/50-usb_power_save.rules

    # lista branca para autosusspensão de USBs
    ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"

Como solução oposta, e se você achar melhor, opte por criar uma lista negra para os dispositivos que não reagem bem com a autossuspensão USB e habilite para todos os outros dispositivos:

    /etc/udev/rules.d/50-usb_power_save.rules

    # lista negra para autossuspensão de USBs
    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"

    ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
    LABEL="power_usb_rules_end"

O tempo de espera ocioso padrão da autossuspensão é controlado pelo parâmetro `autosuspend`, pertencente ao já embutido (built-in) módulo de kernel `usbcore`. Para definir um tempo de espera de 5 segundos ao invés do padrão de 2 segundos, adicione o seguinte parâmetro de kernel ao seu bootloader:

    usbcore.autosuspend=5

De forma semelhante ao `power/control`, o tempo de espera pode ser refinado para cada dispositivo ao definir o atributo `power/autosuspend`. Isto significa que, se desejado de outra forma, a autossupensão pode ser desativada ao defini-la para -1 (e com isso jamais autossuspender):

    /etc/udev/rules.d/50-usb_power_save.rules

    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"

Veja a documentação do kernel Linux para mais informações sobre a gestão de energia em dispositivos USB.

### Disco rígido

Veja a paǵina hdparm#Power management configuration para saber quais configurações pode ser usadas nos parâmetros do dispositivo.

Economia de energia não é efetiva se muitos programas estão frequentemente escrevendo no disco; é possível localizar todos os programas, e como, ou quando, eles escrevem no disco para limitar o uso do driver. Use iotop para descobrir quais programas usam o disco com frequência. Veja na seção Melhorando o desempenho#Dispositivos de armazenamento para mais dicas.

Pequenos ajustes, como a opção noatime, podem ser benéficos. Se memória RAM o suficiente estiver disponível, considere desabilitar ou limitar swappiness, pois o mesmo permite limitar uma boa porção de escrituras no disco.

Para dispositivos Seagate com tecnologia PowerChoice, truques para configurar APM via hdparm não irão funcionar por conta do recurso EPC (Condição de energia estendida). Ao invés de configurar APM, considere instalar openseachestAUR e desativar totalmente o EPC da seguinte maneira abaixo (troque o X pela letra real do dispositivo):

    # openSeaChest_PowerControl --scan
    # openSeaChest_PowerControl -d /dev/sdX -i
    # openSeaChest_PowerControl -d /dev/sdX --showEPCSettings
    # openSeaChest_PowerControl -d /dev/sdX --EPCfeature disable
    # openSeaChest_PowerControl -d /dev/sdX --showEPCSettings

A última invocação pode disponibilizar o seguinte resumo:

    ==========================================================================================
     openSeaChest_PowerControl - openSeaChest drive utilities - NVMe Enabled
     Copyright (c) 2014-2023 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
     openSeaChest_PowerControl Version: 3.3.1-4_1_1 X86_64
     Build Date: Jul  4 2023
     Today: Tue Jul  4 17:49:36 2023        User: root
    ==========================================================================================

    /dev/sdX - ST1000NM0008-2F2100 - ZFA19JG2 - SN02 - ATA

    ===EPC Settings===
            * = timer is enabled
            C column = Changeable
            S column = Savable
            All times are in 100 milliseconds

    Name       Current Timer Default Timer Saved Timer   Recovery Time C S
    Idle A      0            *10           *10           1             Y Y
    Idle B      0            *1200         *1200         3             Y Y
    Idle C      0             6000          6000         16            Y Y
    Standby Z   0             9000          9000         46            Y Y

Os zeros na primeira coluna confirmam a desativação e a interrupção do relógio de disco e do disco giratório de forma bem sucedida.

## Ferramentas e scripts

### Usando um script e uma regra udev

Desde que usuários do systemd possam suspender e hibernar através de `systemctl suspend` ou `systemctl hibernate` e manipular eventos ACPI com `/etc/systemd/logind.conf`, então pode ser interessante remover pm-utils e acpid. Há apenas uma coisa que systemd não pode fazer (até a versão 204 pelo menos): a gestão de energia depende que exista diferenciação entre um sistema conectado pela fonte de alimentação ou pela bateria para funcionar melhor. Para preencher esta lacuna você pode criar uma única regra udev que executa um script enquanto a fonte de alimentação estiver conectada e o desativa quando ausente:

    /etc/udev/rules.d/powersave.rules

    SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/caminho/para/seu/script true"
    SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/caminho/para/seu/script false"

Nota: Você pode usar o mesmo script que pm-powersave usa. Você só precisa fazê-lo executável e colocá-lo em outro lugar (por exemplo `/usr/local/bin/`).

Exemplos de powersave scripts:

- ftw, pacote: ftw-gitAUR
- powersave
- throttlectl, de throttlectlAUR

É esperado que a regra udev logo acima já baste, mas se as suas configurações de energia não forem atualizadas depois de um ciclo de suspensão ou hibernação, então adicione o script em `/usr/lib/systemd/system-sleep/` com o conteúdo abaixo:

    /usr/lib/systemd/system-sleep/00powersave

    #!/bin/sh

    case $1 in
        pre) /caminho/para/seu/script false ;;
        post)
    	if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1
    	then
        		/caminho/para/seu/script true
    	else
        		/caminho/para/seu/script false
    	fi
        ;;
    esac
    exit 0

Um pequeno lembrete: Logo após que criar, deixe seu script com as devidas permissões de execução!

Nota: Tenha em mente que AC0 pode ser diferente em seu notebook/laptop, mude-o se for o caso.

### Imprimindo configurações de energia

Este script imprime configurações de energia e uma variedade de outras propriedades para dispositivos USB e PCI. Note que são necessárias permissões de root para ver todas elas.

    #!/bin/bash

    for i in $(find /sys/devices -name "bMaxPower")
    do
    	busdir=${i%/*}
    	busnum=$(<$busdir/busnum)
    	devnum=$(<$busdir/devnum)
    	titulo=$(lsusb -s $busnum:$devnum)

    	printf "\n\n+++ %s\n  -%s\n" "$titulo" "$busdir"

    	for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)
    	do
    		v=$(cat $ff 2>/dev/null|tr -d "\n")
    		[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";
    		v=;
    	done | sort -g;
    done;

    printf "\n\n\n+++ %s\n" "Módulos de Kernel"
    for mod in $(lspci -k | sed -n '/in use:/s,^.*: ,,p' | sort -u)
    do
    	echo "+ $mod";
    	systool -v -m $mod 2> /dev/null | sed -n "/Parameters:/,/^$/p";
    done

## Permitir usuários que desliguem o sistema

### Eventos de botão e tampa

Os eventos `suspend`, `poweroff` e `hibernate`; respectivamente "suspender", "desligar" e "hibernar", quando acionados ao pressionar um botão ou ao fechar a tampa, são manipulados pelo logind, como descrito pela seção #Eventos ACPI.

### Usando systemd-logind

Se você estiver usando polkit, neste caso usuários em sessões não remotas podem emitir comandos relacionados à gestão de energia contanto que a sessão não esteja quebrada.

Para checar se a sessão está ativa:

    $ loginctl show-session $XDG_SESSION_ID --property=Active

O usuário pode então digitar comandos de systemctl ou adicioná-los aos menus:

    $ systemctl poweroff
    $ systemctl reboot

Outros comandos podem ser usados igualmente, incluindo `systemctl suspend` e `systemctl hibernate`. Veja a seção System Commands em systemctl(1).

### Usando sudo

Instale sudo e permita ao usuário privilégios de sudo, assim o usuário poderá usar comandos de `sudo systemctl` (por exemplo `sudo systemctl poweroff`, `sudo systemctl reboot`, `sudo systemctl suspend` e `sudo systemctl hibernate`). Veja a seção System Commands em systemctl(1).

#### Usuários sem privilégios de sudo

Se usuários devem apenas conseguir usar comandos de desligamento e, entretanto, não ter outros privilégios de sudo, então, como root, adicione os determinados comandos no final de `/etc/sudoers` usando o comando `visudo`. Substitua user pelo nome de usuário e hostname pelo nome de host da máquina.

    user hostname =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot

Agora usuários podem desligar com `sudo systemctl poweroff` e reiniciar com `sudo systemctl reboot`. Usuários que desejem desligar o sistema podem também usar `sudo systemctl halt`. Defina a tag `NOPASSWD:` apenas se não for esperada a solicitação de senha.

## Veja também

- ThinkWiki:How to reduce power consumption
- How to get longer battery life on Linux

Category:

- Power management (Português)

Hidden category:

- Pages or sections flagged with Template:Expansion