Moje zdjęcie

imię: Piotr Sowiński
pseudo: Sadi
wiek: 25
zainteresowania: programowanie, tworzenie stron, linux, elektronika, książki


Creative Commons LicenseJeżeli nie zaznaczono inaczej, wszystkie materiały na tej stronie są objęte licencją Creative Commons by-nc 3.0
Skiny
grey-tea green (standardowy)
light sky blue
carrot orange
Polecam

Bykom STOP! browsehappy.pl - masz kIEpską przeglądarkę? Spam Poison - zatrujmy życie spammerom! Debian GNU/Linux Przeglądarka Opera
Metody kompresji jądra sadi | 12:10 | 03.03.2010
Podczas pisania wczorajszego wpisu zauważyłem, że w jądrze 2.6.33 pojawiła się opcja skompresowania go algorytmem LZO. Postanowiłem wykorzystać tę okazję, żeby sprawdzić jakie rzeczywiście różnice w czasie uruchamiania systemu powoduje zastosowanie każdego z możliwych do wyboru algorytmów. Jak wykonywałem pomiary? Po pierwsze, wyłączyłem automatyczne ładowanie się trybu graficznego (użyłem narzędzia sysv-rc-conf do tymczasowego wyłączenia startowego skryptu kdm). Po drugie, używałem stopera. To prawda, że jest Bootchart, ale mierzy on tylko co do sekundy, a to dla mnie za mała dokładność. Po trzecie, pomiar rozpoczynałem równocześnie z wciśnięciem entera w GRUB, a kończyłem wraz z pojawieniem się linijki zachęcającej do zalogowania. Po czwarte, dla każdego jądra zrobiłem 5 pomiarów i wyliczałem z nich średnie. Oto wyniki:

deb (Gzip)GzipLZMALZOBzip2
pomiar 1 [s]10,7210,0510,4710,4110,66
pomiar 2 [s]11,029,9110,1510,2110,43
pomiar 3 [s]10,829,7810,1410,3210,28
pomiar 4 [s]10,739,9510,2910,3610,32
pomiar 5 [s]11,049,8610,2110,2210,86
średnia [s]10,879,9110,2510,3010,51

Widać, że różnice są minimalne (uwaga - wartości średnie dalej są obarczone pewnym błędem). W każdym razie widać z nich, że stosowany do tej pory Gzip wygrywa z nowym LZO - czyli raczej nie ma sensu zamieniać. Jądro, które oznaczyłem jako "deb (Gzip)" jest wzięte z repozytorium Debiana. Umieściłem je w zestawieniu, żeby przy okazji pokazać różnicę jaką (u mnie) daje pozbycie się initrd. Jak widać są to okolice 1 sekundy.

Aktualizacja (15.03.10)

Podaję rozmiary jąder (w bajtach):
deb (Gzip)GzipLZMALZOBzip2
rozmiar [B]2 371 9043 050 9282 492 0003 328 0002 844 144

Tutaj zaskoczenia nie było - najmniejsze było jądro skompresowane algorytmem LZMA, a największe LZO. Wersja LZO jest większa od wersji Gzip o 9%, więc help w konfiguracji jądra mówi prawdę. Rozmiar jądra z repozytorium Debiana podałem, aby dane były kompletne. Różnica rozmiaru wynika z tego, że dla siebie wkompilowuję trochę dodatkowych rzeczy do jądra.

<< Powrót

Komentarze:

vmario | 12:44 | 06.03.2010
Warto by jeszcze podać rozmiary poszczególnych jąder. Czas wstawania systemu zależy nie tylko od szybkości dekompresji, ale także od czasu wczytywania jądra. LZO teoretycznie powinien być szybszy od Gzipa, ale za to generuje nieco większe pliki, więc ostateczny efekt będzie zależał i od szybkości dekompresji (szybkości procesora), i od szybkości wczytywania (szybkości dysku twardego). W poprzednim wątku pisałem, że rekompilację jądra na PC-cie uważam w większości przypadków za sztukę dla sztuki, jednak odkąd zacząłem portować Linuksa na ARM-a, temat przedstawia się nieco inaczej :) Jeżeli w systemie wbudowanym Linux wstaje kilkanaście sekund to już jest dosyć długo, dlatego warto walczyć o każdą sekundę, by użytkownik mógł pstryknąć włącznik i jak najszybciej korzystać z urządzenia -- stąd wzrastające u mnie zainteresowanie w tym temacie. Przy okazji: co rozumiesz poprzez \"pozbycie się initrd\"? Zastąpiłeś go initramfs, czy po prostu jądro od razu wczytuje sobie właściwy system plików z dysku? Szczerze mówiąc, wciąż jeszcze gubię się w tych niuansach związanych z initrd i initramfs :P
sadi | 12:49 | 10.03.2010
Właśnie sam też skojarzyłem, że przydałoby się podać ich rozmiary, ale w momencie kiedy już pousuwałem te jądra - musiałbym je jeszcze raz skompilować (może faktycznie to zrobię...). Pamiętam jednak, że o ile w helpie przy konfiguracji jądra jest napisane, że spakowane LZO jest 10% większe, niż spakowane Gzipem, to u mnie było prawie 2x większe (może okolice 80%?) - stąd się bierze przegrana LZO. Masz rację, że ogólnie całość rozbija się o stosunek mocy obliczeniowej, do szybkości pracy dysku/pamięci na którym/ej znajduje się jądro. Nie wykluczam, że na systemie wbudowanym wyniki byłyby zupełnie inne. Co do initrd to chodzi o wkompilowanie kluczowych rzeczy w jądro, zamiast kompilacji ich jako moduły, które muszą być załadowane przez initrd. Wtedy możesz zrezygnować z initrd i tracisz przenośność/uniwersalność jądra, ale zyskujesz trochę czasu na starcie. Na moim kompie to była 1 sekunda, na systemie wbudowanym powinno być pewnie kilkakrotnie więcej (o ile nie jest tak, że już nie masz initrd, co na systemie wbudowanym wcale by mnie nie zdziwiło). Jak zrobiłem to u siebie na kompie? http://sadi.ovh.org/blog.php?wpis=69 i http://sadi.ovh.org/arty/debkernel.php (z wywaloną opcją --initrd w komendzie make-kpkg). Wiem, że na systemy wbudowane kompiluje się zupełnie inaczej, ale zawsze to jakaś wskazówka.
vmario | 10:28 | 11.03.2010
Na ARM-a mam skompilowane dwie wersje. Pierwsza to jądro + initramfs w jednym pliku -- służy mi ona do wstępnego podniesienia systemu, pobrania wszystkich obrazów przez LAN i sformatowania NANDFlasha (dzięki temu na ogół nie potrzebuję uruchamiać wbudowanego programatora USB). Druga to samo jądro, które ma prawie wszystko wkompilowane na sztywno, włącznie z obsługą systemu UBIFS, dzięki czemu bez kłopotu podnosi główny system plików z NANDFlasha. Na razie nie eksperymentowałem szczególnie z kompresją itp., ale zauważyłem, że ważne jest, by U-Boot wczytywał jak najmniej danych; można co prawda wczytać obszar pamięci za obrazem jądra, ale zostanie on po prostu zignorowany, a widać gołym okiem różnicę między czasem wczytywania 1,5MB (jądro bez initramfs) a 6MB (cała \"partycja\" zarezerwowana na jądro). W PC-cie myślałem, że mam initrd, bo taki wpis widnieje w konfiguracji GRUB-a, ale z tego co wyczytałem, to mój Arch Linux (jak chyba większość nowoczesnych Linuksów) tak naprawdę korzysta z nowszego i lepszego rozwiązania, tj. initramfs w miejsce initrd. Zarówno initrd i initramfs pełnią tę samą funkcję (choć różnią się w szczegółach technicznych), może dlatego w plik z initramfs jest podawany jako opcja o nazwie initrd. Zresztą chyba zawsze będę się w tym gubił ;)
sadi | 13:31 | 15.03.2010
Z tego co wyczytałem wynika, że initramfs właściwie zastąpił initrd i to już parę lat temu. Jednak w wielu miejscach używa się dalej nazwy initrd, mając faktycznie na myśli initramfs. Przyznam, że nie rozumiem po co na starcie formatujesz flasha i ściągasz obrazy po LANie - to pewnie to zabiera ci najwięcej czasu na starcie (tzn. do testowania różnych jąder to dobre rozwiązanie, ale nie dziw się, że to trwa). Na Blackfinie kolegi uClinux uruchamia się przez jakieś 2-3 sekundy, ale jest wgrany na flasha, niczego nie ściąga po sieci na starcie, ani nie formatuje. Nie możesz zrobić podobnie? Podejrzewam, że wtedy też zjedziesz do paru sekund. Zmieniając temat dodałem rozmiary poszczególnych jąder. Trochę przesadziłem z tym co wcześniej pisałem, że LZO tworzy archiwa o 80% większe, niż Gzip. Wzięło się to stąd, że sprawdzałem te algorytmy również przy pakowaniu źródeł jądra i tam Gzip dał plik o rozmiarze 87 063 976 B, a LZO 135 555 292 B (czyli o 56% więcej). Po prostu pomyliły mi się testy. Na marginesie wyszło na to, że LZO słabo sobie radzi z kompresją tekstu (źródła to właściwie tekst).
vmario | 14:40 | 15.03.2010
Źle mnie zrozumiałeś. Podczas normalnej pracy Linux wstaje z Flasha w ciągu ok. 14 sekund (z czego aż 6 pożera U-Boot, a tylko 8 Linux) i nic nie musi ściągać, ale podczas rozwijania systemu potrzebuję sprawdzać nowe wersje jądra (czasem trzeba to i owo dokompilować) i nowe wersje całego środowiska (Busybox i reszta -- żeby użytkownik końcowy nie musiał wszystkiego ręcznie doinstalowywać, ale miał w jednym obrazie). I właśnie takie wgranie nowej eksperymentalnej wersji systemu odbywa się za pomocą jądra z initramfs. Gdybym użył jądra bez initrafms, system musiałby wstać z Flasha, utworzyć ramdysk, skopiować do ramdysku wszystko co potrzebne, odmontować go i dopiero przystąpić do flashowania. Zresztą niedługo na blogu opublikuję opis mojej metodologii :)
sadi | 22:10 | 17.03.2010
Spoko, rozumiem, że do testowania priorytety są trochę inne, bo ciągle się coś zmienia (normalna sprawa). Jednak nawet z Flasha coś ci długo to wstaje...

Wszystkie przedstawione tutaj opinie należą do ich autorów i twórca strony nie ponosi żadnej odpowiedzialności za ich treść.


Imię/Ksywka (wymagane):

Strona WWW:

Wpisz tekst z obrazka (wymagane):

kod

Treść (wymagane):


W polu "Strona WWW" wpisywanie członu "http://" nie jest konieczne. Tagi (X)HTML wpisane w treści nie będą działać jako element strony, zamiast tego pojawią się w samym komentarzu. Komentarze obraźliwe, nie na temat lub niezgodne z prawem będą w miarę możliwości usuwane.

skiny: grey-tea green | light sky blue | carrot orange
some rights reserved | kanał informacyjny | admin | valid XHTML 1.0 | valid CSS | valid Atom 1.0