Android
Arduino
Blog
Dystrybucje
Filmy
Hardware
KDE 4
KDE 5
Propaganda
Przepisy
Raspberry Pi
Rozrywka
Software
Varia
PRZEWAGA NAD RASPI I NAD ARMAMI..
kezook
BB
True
ori
faucolt
Darek
tomek
kezook
Wbm
Prezent dla użytkowników /dev/Jarzębski #1
Mam dziś malutki prezent dla zarejestrowanych użytkowników /dev/Jarzębski. Są to mianowicie klucze Steam do gier Brutal Legend (1 klucz) oraz Trine 2: Complete Story (1 klucz). Oba tytuły dostępne są również dla Linuksa. Aby otrzymać wybrany przez siebie klucz, należy posiadać konto na Blogu oraz mieć na stanie przynajmniej jeden komentarz przed publikacją tego wpisu. Jeśli jest osoba chętna, proszę o pozostawienie komentarza pod tym wpisem.
Przy okazji zaprszam do aktywności, gdyż planuję więcej, mniejszych lub większych giftów :)
Reklama
Intel o XMir: "Nie popieramy działań Canonicala"
Nastąpił bardzo ciekawy obrót sytuacji w "obozie" Intela, bowiem do nadchodzącej wersji 3.0 sterowników x86-video-intel pojawił się commit dodający obsługę XMir, jednak został on po kilku dniach cofnięty przez Chrisa Wilsona.
Pomimo tego, że łatka pozwalająca na uruchomienie sterowników DDX X.Org pod kontrolą XMir (warstwa serwera Mir od Canonical) była analogiczna do XWayland dla serwera Wayland oraz skomentowana przez Canonical jakoby posiadała już stabilne API, to z jakiegoś powodu nie została ona zaakceptowana.
Najciekawszy okazuje się jednak sam komentarz Chrisa Wilsona, w którym wyjaśnia on powód cofnięcia łatki:
"We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream. -The Management"
"Nie akceptujemy i nie wspieramy firmy Canonical w drodze jaką obrała i nie dostarczymy łatek dla XMir w głównej gałęzi."
Wszystko wskazuje więc na to, że Cannonical będzie musiał dostarczać swoje łatki do Mir/XMir poza oficjalną gałęzią sterowników Intela.
Jedną z nowości zawartych w jądrze 3.9.0 jest zdolność wykorzystywania dysków SSD przez device mappera jako cache dla wolniejszych dysków talerzowych. Idea działania polega na przechowywaniu na mniejszym, ale szybszym dysku SSD kopii plików, do których odwołujemy się najczęściej .
Na niemal identycznej zasadzie działają hybrydowe dyski twarde - np. Seagate Momentus XT. Istotną różnicą jest jednak to, że powyższe rozwiązanie wykorzystuje dwa napędy zamiast jednego.
Konfiguracja testowa
Do testów posłuży nam konwencjolany dysk twardy Western Digital Caviar Black oraz Samsung SSD 830. Platformę testową stanowi Intel i5-2500 wraz z 16GB pamięci RAM.
Przygotowanie dysku SSD
Jedna z cech tego mechanizmu cache z wykorzystaniem dysku SSD jest rozdzielenie jego powierzchni pomiędzy obszarem przechowywania metadanych, a obszarem cache, który będzie gromadził nasze najczęściej wykorzystywane dane. Naturalnie rozmiar cache powinien być jak największy i nie ma większego kłopotu z wyborem jego rozmiaru. Kłopotliwy może być jednak obszar metadanych, którego rozmiar powinniśmy wyliczyć z poniższego wzoru:
4 MiB + (16 B * liczba_bloków)
Rozmiar partycji przyjmiemy 55 GiB, a jako rozmiar bloków 256 KiB - czyli 512 sektorów po 512 B. A więc:
Liczba bloków = 55 GiB / 256 KiB = 225280 bloków
Metadane = 4 MiB + (16 B * 225280) = 7798784 B = 7616 KiB
Przeliczmy jeszcze nasze wartości na 512 B sektory:
Partycja Cache = 55 GiB / 512 = 115343360 sektorów
Partycja Metadanych = 7616 KiB / 512 = 15232 sektory
Za pomocą programu fdisk przygotujemy teraz dysk SSD na podstawie powyższych wartości:
- fdisk -u=sectors -S32 -H32 /dev/sdb
Konfiguracja devmappera
Kiedy mamy już przygotowany dysk SSD, musimy skonfigurować nasz cache. Dla testów ograniczyłem się jednynie do partycji /dev/sda1, do której to będziemy potrzebowli rozmiar w sektorach:
- blockdev --getsz /dev/sda1
- 125788887
Jako rozmiar bloków przyjęliśmy na początku 256 KiB, a więc 512 sektorów.
- dmsetup create ssdcache --table '0 125788887 cache /dev/sdb1 /dev/sdb2 /dev/sda1 512 1 writeback default 0'
Pozostaje nam już tylko zamontować naszą "hybrydę" poniższym poleceniem:
- mount /dev/mapper/ssdcache /mnt/sda1
Testy: Kopiowanie pliku (2,5 GiB)
- echo 3 > /proc/sys/vm/drop_caches
- dd if=/storage/dystrybucje/Slackware/slackware-14.0-install-dvd.iso of=/dev/null
4802704+0 przeczytanych recordów
4802704+0 zapisanych recordów
skopiowane 2458984448 bajtów (2,5 GB), 25,2681 s, 97,3 MB/s
- echo 3 > /proc/sys/vm/drop_caches
- dd if=/mnt/sda1/slackware-14.0-install-dvd.iso of=/dev/null
4802704+0 przeczytanych recordów
4802704+0 zapisanych recordów
skopiowane 2458984448 bajtów (2,5 GB), 20,3597 s, 121 MB/s
Testy: Kopiowanie źródeł jądra 3.9.0 (1,2 GiB)
- echo 3 > /proc/sys/vm/drop_caches
- time cp -R /usr/src/linux-3.9/ /dev/shm/
real 0m48.583s
user 0m0.243s
sys 0m2.513s
- echo 3 > /proc/sys/vm/drop_caches
- time cp -R /mnt/sda1/linux-3.9/ /dev/shm/
real 0m38.133s
user 0m0.253s
sys 0m2.344s
Testy: Kompilacja jądra 3.9.0
- cd /usr/src/linux-3.9
- echo 3 > /proc/sys/vm/drop_caches
- time make -j4
real 6m3.854s
user 19m51.270s
sys 1m29.049s
- cd /mnt/sda1/linux-3.9
- echo 3 > /proc/sys/vm/drop_caches
- time make -j4
real 6m8.074s
user 19m56.077s
sys 1m29.865s
Podsumowanie
Zauważalnych różnic praktycznie nie ma. Jest odrobinę szybciej, jednak należy zastanowić się, czy nie lepszym rozwiązaniem jest postawienie systemu na dysku SSD zamiast stosować cache. Dotyczy się to również testów uruchomieniowych, gdzie programy uruchamiały się praktycznie w tym samym czasie. Przyjrzyjmy się jeszcze na koniec statystykom:
ssdcache: 0 125788887 cache 676/4544 4595 448904 8957 209538 0 607 627 579 0 2 migration_threshold 204800 4 random_threshold 4 sequential_threshold 512
Podczas krótkiej pracy z tym rozwiązaniem można zauważyć, że procent trafień podczas odczytu to zaledwie 1% (4595 trafień i 448904 chybień). Zapis wyszedł trochę lepiej bo, aż porywające 4% (8957 trafień i 209538 chybień).
Czy warto? Moim zdaniem nie - jednak na to pytanie musicie sobie odpowiedzieć sami.
