OptimizationKit jest narzędziem służącym do optymalizacji działania systemu operacyjnego Linux, zgodnie z regułami określonymi w pliku konfiguracyjnym. Pozwala na zmianę “w locie” parametrów pracy planisty zadań CFS, oraz planistów operacji wejścia/wyjścia CFQ, Deadline oraz Aticipatory. Dzięki umiejętnemu wykorzystaniu możliwości tuningowych jądra systemu można w prosty sposób zoptymalizować działanie systemu pod interesujący nas program. Optymalizacja zostanie zastosowana, gdy demon OptimizationKit wykryje instancje programu. W momencie, gdy program zakończy działanie, demon przywróci domyślne parametry pracy systemu, lub zoptymalizuje jego działanie pod inny program znajdujący się w klasie o niższym priorytecie.

Przykładowy rezultat optymalizacji

* domyślna klasa dla gier w trybie działania 0

OptimizationKit pozwala również na wykorzystanie mechanizmu cgroups
w Linuksie 2.6.24+. Dzięki temu możemy podzielić użytkowników systemu
na grupy, którym przydzielimy określoną ilość dostępnych zasobów systemowych.

Instalacja

Pobieramy najnowszą wersję demona ze strony OptimizationKit, następnie rozpakowujemy pliki i uruchamiamy skrypt install.sh (wymagane są prawa administratora).

Konfiguracja

Konfiguracja demona odbywa się przez edycje pliku konfiguracyjnego - domyślnie
/etc/OptimizationKit/OptimizationKit.conf. Plik musi być poprawnym XML
(bo inaczej nie będzie działać

Struktura pliku konfiguracyjnego powinna być następująca:

<cf>
<mode value=”0″ />
<sched_class name=”klasa1″ prio=”10″>
<!–
Parametry danej klasy
–>
</sched_class>
<sched_class name=”klasa2″ prio=”9″>
</sched_class>
<sched_class name=”klasa3″ prio=”6″>
</sched_class>
</cf>

Konfiguracje zaczynamy od określenia trybu działania demona, przez modyfikację
wartości tagu <mode />. Aktualnie dostępnych jest pięć trybów działania
oznaczonych kolejnymi liczbami od 0 do 4, ich opis jest zamieszczony poniżej.

Tryb 0

Jest to tryb znany z wersji 0.0.x (dawniej nazywającej się DeskOpt). Działanie
tego trybu zostanie omówione na poniższym przykładowym pliku konfiguracyjnym.

<cf>
<mode value=”0″ />
<sched_class name=”gry” prio=”10″>
	<scheduler value=”cfs”>
		<cfs_sched_nice value=”-20″ />
		<cfs_sched_batch_wakeup_granularity_ns value=”10000000″ />
		<cfs_sched_min_granularity_ns value=”4000000″ />
		<cfs_sched_runtime_limit_ns value=”16000000″ />
		<cfs_sched_stat_granularity_ns value=”0″ />
		<cfs_sched_wakeup_granularity_ns value=”1000000″ />
	</scheduler>
	<scheduler value=”anticipatory”>
		<anticipatory_sched_antic_expire value=”6″ />
		<anticipatory_sched_write_batch_expire value=”125″ />
		<anticipatory_sched_write_expire value=”250″ />
	</scheduler>
	<app bin=”nexuiz-glx” />
</sched_class>
<sched_class name=”av” prio=”7″>
	<scheduler value=”cfs”>
		<cfs_sched_nice value=”-10″ />
	</scheduler>
	<scheduler value=”cfq”>
		<cfq_sched_nice value=”-c1 -n4″ />
		<cfq_sched_back_seek_max value=”16384″ />
		<cfq_sched_back_seek_penalty value=”2″ />
		<cfq_sched_slice_idle value=”16″ />
		<cfq_sched_slice_sync value=”100″ />
	</scheduler>
	<app bin=”kaffeine” />
	<app bin=”amarokapp” />
</sched_class>
</cf>

Podczas startu demon zapamiętuje domyślne parametry pracy systemu, następnie
co 20 sekund (wartość domyślna, można ją zmienić za pomocą parametru
–loop-time) sprawdza, czy nie pojawił się proces wymieniony w tagach <app />.
Przyjmijmy, że uruchomiliśmy kaffeine, OptimizationKit zapamięta domyślne
parametry nice pracy tego programu (chodzi o parametr nice planisty CFS i CFQ),
a następnie zmieni parametry nice na te zadane w konfiguracji. Załóżmy,
że znudziło się nam oglądanie teledysków, uruchamiamy grę Nexuiz - demon
szybko się dowie o tym fakcie. Ponieważ nexuiz-glx znajduje się w klasie
o wyższym priorytecie, działanie systemu zostanie zoptymalizowane właśnie
pod ten program. OptimizationKit przywróci domyślne wartości nice procesu
kaffeine, oraz domyślne parametry pracy systemu, następnie zajmie się
optymalizacją działania programu nexuiz-glx.

W trybie 0 przy optymalizacji brane są pod uwagę następujące parametry

	<scheduler value="cfs">
		<cfs_sched_nice value=”-20″ />
		<cfs_sched_batch_wakeup_granularity_ns value=”10000000″ />
		<cfs_sched_min_granularity_ns value=”4000000″ />
		<cfs_sched_runtime_limit_ns value=”16000000″ />
		<cfs_sched_stat_granularity_ns value=”0″ />
		<cfs_sched_wakeup_granularity_ns value=”1000000″ />
	</scheduler>
	<scheduler value=”cfq”>
		<cfq_sched_nice value=”-c2 -n0″ />
		<cfq_sched_back_seek_max value=”16384″ />
		<cfq_sched_back_seek_penalty value=”2″ />
		<cfq_sched_fifo_expire_async value=”250″ />
		<cfq_sched_fifo_expire_sync value=”125″ />
		<cfq_sched_quantum value=”4″ />
		<cfq_sched_slice_async value=”40″ />
		<cfq_sched_slice_async_rq value=”2″ />
		<cfq_sched_slice_idle value=”8″ />
		<cfq_sched_slice_sync value=”100″ />
	</scheduler>

Więcej informacji:
http://lwn.net/Articles/101029/
http://lwn.net/Articles/114273/

	<scheduler value="anticipatory">
		<anticipatory_sched_antic_expire value=”6″ />
		<anticipatory_sched_read_batch_expire value=”500″ />
		<anticipatory_sched_read_expire value=”125″ />
		<anticipatory_sched_write_batch_expire value=”125″ />
		<anticipatory_sched_write_expire value=”250″ />
	</scheduler>

Więcej informacji:
Documentation/block/as-iosched.txt

	<scheduler value="deadline">
		<deadline_sched_fifo_batch value=”16″ />
		<deadline_sched_front_merges value=”1″ />
		<deadline_sched_read_expire value=”500″ />
		<deadline_sched_write_expire value=”5000″ />
		<deadline_sched_writes_starved value=”2″ />
	</scheduler>

Więcej informacji:
Documentation/block/deadline-iosched.txt
http://kerneltrap.org/node/431

Tryb 1

Jest to pierwszy tryb posiadający wsparcie dla mechanizmu cgroups, jego
działanie omówię na poniższym przykładzie

<cf>
<mode value=”1″ />
<sched_class name=”gry” prio=”10″>
	<cgroup>
		<memory.limit_in_bytes value=”" />
		<cpuset.cpu_exclusive value=”1″ />
		<cpuset.cpus value=”0-1″ />
		<cpuset.mem_exclusive value=”1″ />
		<cpuset.memory_migrate value=”0″ />
		<cpuset.mems value=”0″ />
		<cpuset.sched_load_balance value=”1″ />
		<notify_on_release value=”0″ />
	</cgroup>
	<app bin=”nexuiz-glx” />
</sched_class>
<sched_class name=”av” prio=”7″>
	<cgroup>
		<memory.limit_in_bytes value=”" />
		<cpuset.cpu_exclusive value=”1″ />
		<cpuset.cpus value=”1-3″ />
		<cpuset.sched_load_balance value=”1″ />
		<notify_on_release value=”0″ />
	</cgroup>
	<app bin=”kaffeine” />
	<app bin=”amarokapp” />
</sched_class>
</cf>

Przy starcie demon montuje w /dev/cgroups system plików służący do sterowania
mechanizmem cgroups. Następnie tworzy w /dev/cgroups dwa katalogi nazywające
się tak samo, jak klasy (gry i av). Gdy wykryje w systemie obecność procesu
należącego do jednej z tych klas, zostanie on dodany do odpowiedniej grupy
w /dev/cgroups.

W tym trybie możemy w łatwy sposób ograniczać dostępną dla procesu pamięć,
oraz zasoby procesora - np. programom “systemowym” możemy pozwolić pracować
tylko na jednym rdzeniu i ograniczyć dostępną dla nich pamięć.

W trybie 1 brane są pod uwagę następujące parametry

<cgroup>
<!–		<memory.limit_in_bytes value=”" />–>
		<cpuset.cpu_exclusive value=”1″ />
		<cpuset.cpus value=”0-1″ />
		<cpuset.mem_exclusive value=”1″ />
		<cpuset.memory_migrate value=”0″ />
		<cpuset.memory_pressure value=”0″ />
		<cpuset.memory_pressure_enabled value=”0″ />
		<cpuset.memory_spread_page value=”0″ />
		<cpuset.memory_spread_slab value=”0″ />
		<cpuset.mems value=”0″ />
		<cpuset.sched_load_balance value=”1″ />
		<notify_on_release value=”0″ />
</cgroup>

W przeciwieństwie do trybu 0 w trybie 1 podczas wyłączania demona nie jest
możliwe przywrócenie stanu systemu z przed uruchomienia demona. Dzieje się
tak dlatego, ponieważ aktualna implementacja cgroups w jądrze systemu
(Linux 2.6.24) nie daje możliwości usunięcia procesu z grupy, ani usunięcia
grupy dopóki znajdują się w niej jakieś procesy (zamknięte koło ;).
Usunięcie grupy jest możliwe tylko wtedy, gdy wszystkie przydzielone
do niej procesy zakończą działanie.

Ograniczanie pamięci dla grupy przez modyfikację taga <memory.limit_in_bytes />
jest możliwe na Linuksie 2.6.25 (w tej wersji włączono kontroler pamięci),
lub na odpowiednio połatanym systemie.

Tryb 2

Tryb 2 jest połączeniem trybu 0 i 1. Tak, jak w trybie 1 przydziela on procesy
do zdefiniowanych grup, dodatkowo (tak jak w trybie 0) optymalizuje pracę
systemu pod proces znajdujący się w klasie o najwyższym priorytecie.

Tryb 3

W trybie 3 do grup dodawane są procesy należące do poszczególnych użytkowników.

Poniższy plik konfiguracyjny pozwala na przydzielenie dwóm użytkownikom
(michal i admin) 1 rdzenia CPU a trzech innych użytkowników systemu
(anna, maciek, jolanta) dostaje do dyspozycji trzy pozostałe rdzenie.

<cf>
<sched_class name=”cgroup0″ prio=”0″>
	<cgroup>
		<cpuset.cpus value=”0″ />
		<cpuset.sched_load_balance value=”1″ />
		<notify_on_release value=”0″ />
	</cgroup>

	<user uname=”michal” />
	<user uname=”admin” />
</sched_class>
<sched_class name=”cgroup1″ prio=”0″>
	<cgroup>
		<cpuset.cpus value=”1-3″ />
		<cpuset.sched_load_balance value=”1″ />
		<notify_on_release value=”0″ />
	</cgroup>

	<user uname=”anna” />
	<user uname=”maciek” />
	<user uname=”jolanta” />
</sched_class>
</cf>

W trybie 3 brane są pod uwagę wszystkie parametry, które są uwzględniane
w trybie 1.

Tryb 4

Tryb 4 ma działanie analogiczne do trybu 3, różnica polega na tym, że zamiast
nazw użytkownika podajemy nazwy grup. Tryb może być przydatny, gdy np. chcemy
rozdzielić zasoby uczelnianego serwera pomiędzy profesorów i studentów.
Wystarczy stworzyć dwie klasy

<cf>
<sched_class name=”prof” prio=”0″>
	<cgroup>
		<cpuset.cpus value=”0″ />
		<cpuset.sched_load_balance value=”1″ />
		<notify_on_release value=”0″ />
	</cgroup>

	<group gname=”prof1″ />
	<group gname=”prof2″ />
</sched_class>
<sched_class name=”stud” prio=”0″>
	<cgroup>
		<cpuset.cpus value=”1-3″ />
		<cpuset.sched_load_balance value=”1″ />
		<notify_on_release value=”0″ />
	</cgroup>
	<group gname=”studenci” />
</sched_class>
</cf>

OptimizationKit i SELinux

Domyślne polityki SELinuksa ograniczają możliwość tworzenia katalogów
w /dev/cgroups - jest to potrzebne do działania OptimizationKit
w trybach 1,2,3,4. Rozwiązanie tego problemu jest bardzo proste - wystarczy
stworzyć moduł do polityki bezpieczeństwa umożliwiający tworzenie tych
katalogów.

Zaczynamy od skopiowania AVC z pliku /var/log/audit/audit.log (lub
/var/log/messages jesli nie używamy auditd) do pliku audit.txt - powinno
wyglądać mniej więcej tak:

type=AVC msg=audit(1205327104.415:184): avc:  denied  { associate } for
 pid=12620 comm="mkdir" name="audio" scontext=unconfined_u:object_r:
unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
type=SYSCALL msg=audit(1205327104.415:184): arch=40000003 syscall=39
success=no exit=-13 a0=bfce2c56 a1=1ff a2=804e818 a3=1ff items=0
ppid=12535 pid=12620 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts1 comm="mkdir" exe="/bin/mkdir"
subj=unconfined_u:system_r:unconfined_t:s0 key=(null)

Następnie wykonujemy

# cat audit.txt | audit2allow -m local > local.te

Plik local.te powinien wyglądać mniej więcej tak

module local 1.0;

require {
        type unlabeled_t;
        class filesystem associate;
}

#============= unlabeled_t ==============
allow unlabeled_t self:filesystem associate;

Następnie wykonujemy

# checkmodule -M -m -o local.mod local.te
# semodule_package -o local.pp -m local.mod
# /usr/sbin/semodule -i local.pp

Teraz SELinux nie powinien powstrzymywać OptimizationKit przed tworzeniem
katalogów w /dev/cgroups.

Problemy z OptimizationKit

Projekt jest we wczesnej fazie rozwoju i może sprawiać wiele problemów.
Przed zgłoszeniem błędu proszę o sprawdzenie, czy plik konfiguracyjny na pewno
ma poprawny format XML (wystarczy zmienić rozszerzenie na .xml i otworzyć
w Firefoksie). Jeśli plik konfiguracyjny jest ok, to proszę zajrzeć
do /var/log/OptimizationKit.log - tam powinien znajdować się traceback błędu

Traceback (most recent call last):
  File "./OptimizationKit", line 98, in <module>
    start()
  File "./OptimizationKit", line 34, in start
    start_mode_2(opts)
  File "/home/michal/Projekty/OptimizationKit/OptimizationKit-dev/
  src/ok_mode_2.py", line 50, in start_mode_2
	...
	...
	etc

Proszę o wysłanie go razem z użytym plikiem konfiguracyjnym na adres - antyspam - proszę zajrzeć do dokumentacji

TODO

• poprawić wszystkie błędy
• skrypty startowe dla innych dystrybucji (na razie jest dla CentOS/Fedora/RHEL)
• kod w ok_mode_0, ok_mode_2 i ok_opt brzydko wygląda…
• moduł umożliwiający prefetch wybranych programów przy starcie demona

Autor tego artykułu jest twórcą OptymalizationKit