Table of Contents

Linux 2.6.32

Istotne zmiany mogące w zasadzie1) trafić do jądra jedynie poprzez okno scalania (ang. merge window), które tym razem trwało nieco ponad dwa tygodnie, są już znane. Finalna wersja też już ujrzała światło dzienne.

Nowy kernel nie posiada wyjątkowo chwytliwych nowości, które mogłyby doprowadzić do wybuchów radości zwykłych użytkowników. Nie znaczy to jednak, że nie warto nic o nim powiedzieć, w końcu nie powstałby chyba wówczas ten tekst.

UWAGA: Tekst publikuję obecnie w stadium beta, a gdy będę miał więcej czasu, najprawdopodobniej zostanie uzupełniony. Zawiedzionych z góry przepraszam obniżonym standardem w stosunku do moich poprzednich, dłuższych tekstów.

Trochę statystyk

Spójrzmy najpierw na ostatnie 3 lata rozwoju (wersja 2.6.19 została wydana 29 listopada 2006 roku).

Wersja Commity Autorzy Dni
2.6.19 6685 836 70
2.6.20 4768 687 66
2.6.21 5016 788 80
2.6.22 6526 910 73
2.6.23 6662 945 92
2.6.24 9836 1014 107
2.6.25 12243 1169 83
2.6.26 9941 1054 87
2.6.27 10628 1058 88
2.6.28 9048 1119 76
2.6.29 11718 1233 88
2.6.30 11989 1188 78
2.6.31 10883 1214 91
2.6.32 10998 1286 83

Począwszy od 2.6.26 nowe wersje jądra wychodzą średnio co 85 dni, z prawie nieustannie rosnącą liczbą autorów jak i samych commitów. Widać, że jądro rozwija się dość dynamicznie.

Po wersji 2.6.31 tylko 9 autorów przekroczyło barierę 100 commitów. 7 plików zmieniło nazwę, 10.308 plików uległo zmianie, dodano 1.091.771 linii, a usunięto 529.314, co daje efektywnie wzrost liczby linii jądra o przeszło 550 tysięcy. Łącznie w jądrze znajduje się 30.486 plików, 25.061.056 linii, a to wszystko waży 341 MB.

Pdflush na emeryturze

Wątki jądra (od 2 do 8 w zależności od ilości pracy do wykonania)2) odpowiedzialne za zapis brudnych stron cache'u (ang. dirty pages)3) na żądanie poprzez wywołanie systemowe sync() lub w 3 następujących przypadkach:

zostały zastąpione nowym rozwiązaniem, w którym przestaje się operować na wszystkich dyskach jak miało to miejsce dotychczas. To BDI, czyli backing device info (informacja o urządzeniu zrzucającym) stanowi podstawową jednostkę, na jakiej operują nowe wątki.

Wątki flushera per-BDI pozwalają uzyskać lepszą wydajność, szczególnie w konfiguracjach wielodyskowych. Z problemami jakie występowały w starym podejściu (m.in. nieblokujący charakter pdflush mogący prowadzić do zagłodzenia z braku wolnych żądań I/O spowodowanego przepełnieniem kolejek przez nieustannie piszące po dysku aplikacje) i ze szczegółami nowego można się zapoznać w artykule na LWN lub poglądowo dzięki prezentacji samego twórcy.

Prezentacje

LWN

Maile

Commity

Odmieniony devfs powraca

Mianem devfs2 Andrew Morton określił, jego zdaniem zbędnego, patcha, za którym stoją Kay Sievers, Jan Blunck i Greg Kroah-Hartman, ponownie4) wprowadzającego mechanizm pozwalający wypełnić katalog /dev z poziomu jądra.

Stary devfs wprowadzał odrębny wirtualny system plików, natomiast nowy devtmpfs wykorzystuje tmpfs (podobnie jak udev), który jest dynamicznie modyfikowany tak aby zawsze oddawał aktualny stan urządzeń w jądrze (co jest istotne np. w obliczu dynamicznej numeracji urządzeń blokowych, gdzie statyczne podejście, obecne onegdaj właśnie w devfs, nie działa). Jednakże może być zmieniany z poziomu przestrzeni użytkownika – zmiana uprawnień któregokolwiek węzła urządzenia oznacza, że devtmpfs przestaje się nim interesować, tzn. nie dba o usunięcie go kiedy urządzenie zostanie odłączone. Tym samym obecne wersje udev-a działają z nim bez problemu.

Morton w pierwszym komentarzu napisał: “Lol, devfs.” Kroah-Hartman odpowiedział, że to devfs tylko “zrobiony prawidłowy” i, miejmy nadzieję, pozbawiony problemów z vfs dotykających devfs-a. Zachęcam do przejrzenia całej, wcale nie takiej skromnej, dyskusji. W skrócie można napisać, że włączenie devtmpfs do jądra odbyło się mimo sprzeciwu wielu deweloperów.

LWN

Maile

Commity

Na pohybel powtarzającej się pamięci

Kernel Samepage Merging (wcześniej znany jako Kernel Shared Memory) to rozwiązanie pozwalające na wykrywaniu i “zwalnianiu” powtarzających się stron pamięci. Specjalny daemon jądra ksmd okresowo skanuje pamięć w poszukiwaniu identycznych stron pamięci mogących zostać zastąpionymi jedną instancją strony tylko do odczytu, która przy próbie modyfikacji przez proces jest automatycznie kopiowana. Obszar pamięci poddawany takiemu przeglądaniu deklaruje się z pomocą wywołania systemowego madvise() (madvise(addr, length, MADV_MERGEABLE)).

Pozwala to nam na zmniejszenie użycia pamięci, szczególnie w środowiskach służących do wirtualizacji, gdzie uruchomionych równolegle jest wiele identycznych lub bardzo podobnych maszyn wirtualnych. Mechanizm ten był pierwotnie stworzony dla KVM (Kernel-based Virtual Machine), ale może być używany także z innymi systemami wirtualizacji czy w ogóle bez nich.

LWN

Maile

Dokumentacja

Commity

Zmiany w planiście

FIXME

Inne nowości

Równie ciekawe nowości to:

Pozostałe zmiany

Warto jeszcze wspomnieć o co najmniej kilku usprawnieniach:

Download

Nie sposób opisać wszystkiego, co uległo zmianie od poprzedniej wersji jądra. Najlepiej po prostu je pobrać i samemu potestować.

Najnowszy kernel można ściągnąć spod adresu:

W bezsenne tygodnie natomiast gorąco polecam przejrzeć ChangeLog, w którym wszystkie zmiany są wymienione. Jeżeli wolimy je przeczytać w bardziej zwartej formie, konieczne jest odwiedzenie strony KernelNewbies.org i ich wpisu nt. wersji 2.6.32. Gdy i ta ilość tekstu przeraża Cię, LWN nadciąga z pomocą:

Szybkich kompilacji i bezproblemowej pracy z nowym jądrem życzę.

1) zdarzały się parokrotnie sytuacje kiedy to większe zmiany trafiały później niż w -rc1, a wynikało to np. z przemycania kodu przez zaufanych “podwładnych” Linusa czy też nietypowej akceptacji, przez tegoż samego Fina, włączenia spóźnionego sterownika
2) ich liczbę można sprawdzić pod /proc/sys/vm/nr_pdflush_threads
3) tzn. takich, które uległy zmianie w stosunku do fragmentu magazynu danych, który odtwarzają w pamięci operacyjnej – zmiany te nie trafiły jeszcze na niego, bo standardowo są zrzucane co 30 sekund
4) devfs trafił do jądra w wersji 2.3.46, ale nigdy nie zyskał większego uznania; w 2.6.13 został wyrzucony z Kconfigu, później był powoli usuwany z różnych miejsc, ale dopiero w 2.6.18 został kompletnie usunięty dzięki patchom Grega KH; w 2.6.19 wymazano jeszcze tylko kilka śladów jego “rzekomej” egzystencji