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.
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.
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:
/proc/sys/vm/dirty_ratiozostał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
d8a8559 writeback: get rid of generic_sync_sb_inodes() export66f3b8e writeback: move dirty inodes from super_block to backing_dev_info03ba378 writeback: switch to per-bdi threads for flushing datad0bceac writeback: get rid of pdflush completelyf09b00d writeback: add some debug inode list counters to bdi statsd993831 writeback: add name to backing_dev_info500b067 writeback: check for registered bdi in flusher add and inode dirty
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
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
828502d ksm: add mmu_notifier set_pte_at_notify()3866ea9 ksm: first tidy up madvise_vma()d19f352 ksm: define MADV_MERGEABLE and MADV_UNMERGEABLEf8af4da ksm: the mm interface to ksm21333b2 ksm: no debug in page_dup_rmap()9a84089 ksm: identify PageKsm pages31dbd01 ksm: Kernel SamePage Merging1ff8299 ksm: prevent mremap move poisoning36b2528 ksm: change copyright message339aa62 ksm: change ksm nice level to be 5b402826 ksm: rename kernel_pages_allocatede178dfd ksm: move pages_sharing updates473b0ce ksm: pages_unshared and pages_volatile26465d3 ksm: break cow once unshared6e15838 ksm: keep quiet while list empty81464e30 ksm: five little cleanupsd952b79 ksm: fix endless loop on oomcd551f9 ksm: distribute remove_mm_from_lists9ba6929 ksm: fix oom deadlock1c2fb7a ksm: fix deadlock with munlock in exit_mmap2ffd867 ksm: sysfs and defaults7701c9c ksm: add some documentation8314c4f ksm: remove VM_MERGEABLE_FLAGSa913e18 ksm: clean up obsolete references
Równie ciekawe nowości to:
Warto jeszcze wspomnieć o co najmniej kilku usprawnieniach:
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ę.
-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/proc/sys/vm/nr_pdflush_threadsdevfs 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