Blog

Zarządzanie energią – dyskusja

Ostatnimi czasy miałem okazję wziąć udział w żywej dyskusji dotyczącej wyższości poszczególnych systemów operacyjnych. Jako osoba związana ze światem Linuksa, dla którego inne systemy nie są jednak tajemnicą i – co więcej – zdarza mi się z nich korzystać, chętnie się w nią włączyłem. Podczas – jak się potem okazało – kilkugodzinnej (przerywanej czynnościami „bankietowymi”) dyskusji zostało poruszone wiele wątków, a wśród nich:

• wydajność i skalowanie ze względu na ilość CPU;
• skalowanie zarządzania pamięcią RAM;
• możliwości uruchamiania oprogramowania profesjonalnego;
• wsparcie chmurowe;
• możliwości uruchamiania gier;
• codzienne użytkowanie;
• możliwości prac „artystycznych”;
• czas pracy na baterii;
• poziom wejścia.

Oczywiście w większości z nich bezapelacyjnie wygrywa jedynie słuszna rodzina systemów, oparta o otwarte jądro. W niektórych przewaga systemów Windows jest bezapelacyjna (stacje do grania). W innych przypadkach systemy spod znaku Apple, pomimo ceny, jak i zamkniętości, biją na głowę wszystkie inne rozwiązania. Sama dyskusja w swoim zamiarze oficjalnie nie miała na celu wskazania „najlepszego” rozwiązania, jednak każdy ze zwolenników chciał wyjść z niej „zwycięsko”.

Muszę to rozchodzić

Jednym z ciosów, który sprawił, że przez chwilę zwątpiłem w szanse absolutnego zwycięstwa Linuksa, była następująca wypowiedź: Jestem osobą dużo pracującą w podróży. Gdy dostaje komputer z Windowsem lub „Maka”, to od razu wiem, że mogę liczyć na dobre czasy pracy na baterii. Gdy zaś dostaje podobną konfigurację z Linuksem, to tracę dobre 70% mobilności.

Bez mrugnięcia okiem przyznałem mojemu rozmówcy rację (w retoryce można to zrobić po to, by uwiarygodnić drugą część zdania będąca już obroną lub wręcz atakiem) i odpowiedziałem: Nietrudno nie zgodzić się z faktami – rzeczywiście komputery przenośnie pracujące pod GNU/Linuksem z reguły pracują krócej na jednym cyklu życia baterii. Jednak należy podkreślić, że Linux jako rozbudowana platforma pozwala na wyjątkowo głęboką konfigurację, co może zaowocować nawet lepszymi wynikami niż te osiągane pod kontrolą innych systemów. Tak przynajmniej zapamiętał to mój umysł – w jakim stanie był, pozostawiam słodkiemu niedopowiedzeniu.

Odrobinkę, ciutkę, citukę późniejszą godziną, schodząc z parkietu i delikatnie kulejąc (doznałem bowiem niegroźnej kontuzji) spotkałem mojego dobrego przyjaciela, który spytał mnie, czy coś mi się stało. Odpowiedziałem: A wiesz, XXXX podał dobry argument, czemu Windows jest naprawdę lepszy od Linuksa i muszę to rozchodzić”. Mój przyjaciel jako osoba technologicznie wykluczona normalna nie zrozumiał.

Dłuższe czasy na baterii – krótkie wprowadzenie

Jak już było powiedziane, Linux umożliwia prawdziwie elastyczne zarządzanie energią. Oprócz standardowego wykorzystania ACPI (Advanced Configuration and Power Interface), istnieją również takie możliwości jak wyłączanie poszczególnych rdzeni/wątków procesora, odłączanie urządzeń czy ustawianie maksymalnej częstotliwości procesora na absurdalnie niską wartość. Oczywiście „ceną”, jaką z reguły musimy zapłacić, jest wydajność naszego komputera. Niemniej w związku ze specyfiką dzisiejszych notebooków (duża moc, niewielka możliwość odprowadzenia ciepła) zdarza się, że laptop na ustawieniach oszczędzających energię, będzie pracował szybciej niż ustawieniach nastawionych na wydajność. Najlepszą ilustracją i potwierdzeniem tego zjawiska jest undervolting. Dla przykładu Dell XPS 15 potrafi być o 15% szybszy na wolniejszych ustawieniach procesora – więcej informacji znajdą Państwo pod tym adresem https://www.notebookcheck.net/Dell-XPS-15-9570-15-more-performance-by-undervolting.317738.0.html.

W świecie Linuksa istnieją 3 popularne sposoby, dzięki którym można zoptymalizować czas użycia baterii:

1. TLP.
2. PowerTop.
3. Statyczne pliki i skrypty.

Wszystkie z nich zostaną przestawione w tej krótkiej serii. Na samym początku zajmiemy się TLP. Następnie przejdziemy do PowerTop, by na końcu podjąć tematykę najtrudniejszych w utrzymaniu plików statycznych i kilku zaawansowanych opcji. W trzecim artykule znajdą się też dodatkowe uniwersalne porady i podsumowanie całej serii.

Zacznijmy jednak od początku :)

TLP – ThinkPad Linux Power

Skrótowiec ThinkPad Linux Power – TLP jest moją mnemotechniką, której używam w jakże oczywistym celu zapamiętania nazwy programu. Nie jest to jego oficjalna nazwa. Niemniej TLP jest projektem, który rozpoczął się w pięknych czasach świetności symbiozy ThinkPad + Linux. W związku z tym, oprócz dostarczania uniwersalnych narzędzi pozwalających na zarządzanie energią, posiada także dedykowane rozwiązania pod laptopy niegdyś od IBM, a od dłuższego już czasu od Lenovo.

TLP możliwości

Jak większość narzędzi wspomagających zarządzanie energią, TLP posiada dwa tryby pracy – praca na baterii i praca z zasilaniem sieciowym. Przełączenie odbywa się automatycznie, gdyż TLP wrzuca swoje zasady (rules) do udev.

Zgodnie ze stroną projektu TLP posiada następujące możliwości:

TLP applies the following settings depending on the power source (battery / ac):

    Kernel laptop mode and dirty buffer timeouts;
    Processor frequency scaling including "turbo boost" / "turbo core";
    Power aware process scheduler for multi-core/hyper-threading;
    Hard disk advanced power management level and spin down timeout (per disk);
    SATA aggressive link power management (ALPM);
    PCI Express active state power management (PCIe ASPM) – Linux 2.6.35 and above;
    Runtime power management for PCI(e) bus devices – Linux 2.6.35 and above;
    Radeon KMS power management – Linux 2.6.35 and above, not fglrx;
    Wifi power saving mode – depending on kernel/driver;
    Power off optical drive in drive bay (on battery).

Additional TLP functions:

    I/O scheduler (per disk);
    USB autosuspend with blacklist;
    Audio power saving mode – hda_intel, ac97;
    Enable or disable integrated wifi, bluetooth or wwan devices upon system startup and shutdown;
    Restore radio device state on system startup (from previous shutdown);
    Radio device wizard: switch radios upon network connect/disconnect and dock/undock;
    Disable Wake On LAN;
    WWAN state is restored after suspend/hibernate;
    Undervolting of Intel processors – requires kernel with PHC-Patch;
    Battery charge thresholds – ThinkPads only;
    Recalibrate battery – ThinkPads only.

W związku z trudnym tłumaczeniem (np. ustawienie energio-świadomego planisty systemowego dla wielordzeniowych systemów), które w dużej mierze nie odda sensu pierwowzoru, pozwolę sobie wyjątkowo pominąć tłumaczenie.

Niemniej z istotnych funkcji należy na pewno wymienić (częściowo przetłumaczyć):

• wejście w tryb laptopa (/proc/sys/vm/laptop_mode) i związane z tym zmiany w dostępie, odczycie i zapisie dysków;
• zmiany w ustawieniach skalowania częstotliwości procesorów oraz w ustawieniach planisty systemowego;
• ustawienia oszczędzania energii na urządzeniach WIFI, bluetooth i WWAN;
• przejście w tryb automatycznego zawieszenia na USB i karcie audio;
• wyłączenie Wake On Lan.

TLP instalacja

W rodzinie Linuksów typu Enterprise pakiety TLP mogą zostać zainstalowane z repozytorium EPEL. Pozwolimy sobie także na instalację dodatkowych narzędzi związanych z łącznością bezprzewodową (pakiet LTP Radio Device Wizard (rdw)).

sudo yum install -y epel-release && sudo yum install -y tlp tlp-rdw

Dla Fedory (i w przyszłości Enterprise Linuksa [będzie wymagać repozytorium EPEL] w wersji 8) wystarczy wykonać:

sudo dnf install -y tlp tlp-rdw

TLP użycie

Po instalacji możemy w końcu włączyć (enable) i uruchomić (start) TLP.

sudo systemctl enable tlp
sudo systemctl start tlp

Na tych dwóch poleceniach moglibyśmy zakończyć artykuł. Wynika to z faktu, iż TLP jest praktycznie bezobsługowy. Można rzecz nawet TFU… bezkonfigurowalny. Po zainstalowaniu posiada on domyślne akceptowalne ustawienia zoptymalizowane pod oszczędzanie energii. Oczywiście istnieje możliwość dalszej konfiguracji, wymaga ona jednak większej wiedzy na temat naszego środowiska, a także minimalnej wiedzy na temat konfiguracji jądra.

Jak nietrudno się domyślić, TLP „wrzuca” nam kilka programów. W celu wylistowania ich pozwoliłem sobie użyć zapytania polecania rpm.

[root@Normandy ~]# rpm -ql tlp tlp-rdw | grep bin
/usr/bin/bluetooth
/usr/bin/run-on-ac
/usr/bin/run-on-bat
/usr/bin/tlp-pcilist
/usr/bin/tlp-stat
/usr/bin/tlp-usblist
/usr/bin/wifi
/usr/bin/wwan
/usr/sbin/tlp

Większość z nich jest skryptami, jednak niektóre to linki symboliczne.

[root@Normandy ~]# rpm -ql tlp tlp-rdw | grep bin | xargs file
/usr/bin/bluetooth:   POSIX shell script, ASCII text executable
/usr/bin/run-on-ac:   POSIX shell script, ASCII text executable
/usr/bin/run-on-bat:  symbolic link to `run-on-ac'
/usr/bin/tlp-pcilist: Perl script, ASCII text executable
/usr/bin/tlp-stat:    POSIX shell script, UTF-8 Unicode text executable
/usr/bin/tlp-usblist: Perl script, ASCII text executable
/usr/bin/wifi:        symbolic link to `bluetooth'
/usr/bin/wwan:        symbolic link to `bluetooth'
/usr/sbin/tlp:        POSIX shell script, ASCII text executable

Mówiąc szczerze, bardzo nie lubię rozwiązania, które autor TLP zaimplementował. W przypadku grupy skryptów bluetooth/wifi/wan mamy do czynienia z różnym działaniem skryptu ze względu na nazwę, z jaką skrypt został wykonany. Pozwolę sobie wkleić kawałek /usr/bin/bluetooth.

self=${0##*/}

case $self in
    bluetooth|wifi|wwan)
        case $1 in
...
    *)
...
esac

Zgodnie z kodem, skrypt zaczytuje, po jakiej nazwie został wywołany i ze względu na nią, podejmuje dalsze działania. Nie jest to niespotykane w systemach Linuksowych, ale pomimo swoich zalet pozostawia pewien „niesmak”. Jako ciekawostkę chciałbym dodać, iż podobna sytuacja występuje dla przykładu w komendzie reset, która jest miękkim dowiązaniem (soft link) do komendy tset. Komenda tset sprawdza, czy została wywołana jako reset i ze względu na to, ustawia odpowiednią flagę i wchodzi w tryb resetowania terminala.

Wracając jednak do TLP i jej komend, pozwolę sobie wypisać co najważniejsze.

tlp-stat

tlp-stat służy do wypisywania ustawień zarządzania energią. Wywołanie tlp-stat bez argumentów, zwróci nam informację odnośnie załadowanej konfiguracji i wszystkich aktywnych ustawień. By poznać inne opcje, proponuję wywołać wraz z flagą (argumentem) -h lub --help. tlp-stat w ramach pomocy do programu wylistuje listę możliwych argumentów.

[root@Normandy ~]# tlp-stat --help
Usage: tlp-stat [ -b | --battery   | -c | --config    |
                  -d | --disk      | -e | --pcie      |
                  -g | --graphics  | -p | --processor |
                  -r | --rfkill    | -s | --system    |
                  -t | --temp      | -u | --usb       |
                  -w | --warn      | -v | --verbose   |
                  -P | --pev       |    | --psup      |
                  -T | --trace ]

Zauważmy, że tlp-stat można wywoływać z wieloma argumentami naraz. Jednak ich wykonanie odbywa się od prawej do lewej, np.

tlp-stat -b -u -s

wypisze swoje informacje w kolejności system, uSB, bateria.

tlp

Główny program TLP, jak nietrudno się domyślić, to tlp. Jest on opisywany jako drugi w kolejności, gdyż jest rzadziej wykonywany. Odpowiada za aplikowanie ustawień oszczędzania energii. Jak już wcześniej wspominałem, zmiana tych ustawień opiera się na wydarzeniach udev. Plikiem reguł jest /usr/lib/udev/rules.d/85-tlp.rules.

[root@Normandy ~]# cat /usr/lib/udev/rules.d/85-tlp.rules
# tlp - udev rules
#
# Copyright (c) 2018 Thomas Koch <linrunner at gmx.net>
# This software is licensed under the GPL v2 or later.

# handle change of power source ac/bat
ACTION=="change", SUBSYSTEM=="power_supply", RUN+="/usr/sbin/tlp auto"

# handle added usb devices (exclude subdevices via DRIVER=="USB")
ACTION=="add", SUBSYSTEM=="usb", DRIVER=="usb", ENV{DEVTYPE}=="usb_device", RUN+="/lib/udev/tlp-usb-udev %p"

Zgodnie z regułą, podczas zmiany między zasilaniem sieciowym a baterią, uruchamiana jest komenda /usr/bin/tlp auto.

Sam tlp w przeciwieństwie tlp-stat nie posiada flagi -h lub --help. Niemniej, w związku z nieobsługiwanym wejściem, dostaniemy informację o możliwych wejściach.

[root@Normandy ~]# tlp --help
Error: unknown command "--help".
Usage: tlp start|true|bat|false|ac|usb|bayoff|discharge|setcharge|fullcharge|recalibrate|stat|diskid
[root@Normandy ~]# echo $?
3

Pozwolę sobie wypisać interesujące (niezwiązane z notebookami z serii ThinkPad) opcje:

•  tlp ac jak i tlp false uruchamiają tryb pracy na zasilaniu sieciowym (nadpisując obecny tryb);
• tlp bat jak i tlp true uruchamiają tryb pracy na baterii (nadpisując obecny tryb);
• tlp stat jest równe tlp-stat;
• tlp usb wyłącza auto-suspend (w luźnym tłumaczeniu auto wstrzymania) dla USB.

Plik konfiguracyjny TLP znajduje się w /etc/default/tlp. W celu ustawienia bardziej zaawansowanych opcji oszczędzania energii proponuję w pierwszej kolejności go przeczytać i przed edycją odpowiedzieć sobie na jedno ważne, ale to bardzo ważne pytanie – czy naprawdę mamy pojęcie, co chcemy zmienić/ulepszyć :)

Wyniki

Po zainstalowaniu i uruchomieniu TLP udało mi się uzyskać ponad 6 godzin pracy w domowych warunkach. Podczas gdy bez TLP było to około 5 godzin. Biorąc pod uwagę, że osiągnąłem to w wersji minimalnej, bez dodatkowej konfiguracji, a są to dosłownie 3 komendy, trudno nie być zadowolonym z ponad 20% wzrostu czasu pracy. Pełną listę wyników zostanie zaprezentowane w ostatniej części cyklu.

Czytelników natomiast gorąco zachęcam do sprawdzenia, jak TLP wpłynie na ich czas pracy na baterii.

Podsumowanie

W artykule zostały przedstawione informacje na temat oszczędzania energii przy pomocy popularnego, de facto niewymagającego dodatkowej konfiguracji programu TLP. Jego niewątpliwą zaletą jest wielokrotnie już wspominana prostota. Jest to rozwiązanie typu „Fire-and-Forget” (wojskowy termin oznaczający odpal i zapomnij). Po instalacji, włączeniu (automatyczny start wraz z systemem [multi-user.target]) i uruchomieniu, możemy zapomnieć aż do śmierci laptopa lub reinstalacji systemu (w przypadku systemów z rodziny Enterprise Linux raczej to pierwsze).

W następnej części zajrzymy do popularnego i nieco konkurencyjnego rozwiązania PowerTop.