Kwn2

Kernel Weekly News 2 (30-IV-2007 - 6-V-2007)

Witaj w drugim odcinku tygodnika wiadomości ze świata jądra Linux. Jest on wzorowany na wydawanym kiedyś Kernel Traffic i będę w nim zamieszczał skróty ciekawszych dyskusji toczących się na Linux Kernel Mailing List. Teksty nie są tłumaczone dosłownie, skupiam się raczej na przekazaniu sensu danej wypowiedzi, czasami też w nawiasie umieszczam krótki komentarz, który ma za zadanie rozjaśnić niektóre sformułowania/aluzje/etc.

W tym odcinku można poczytać o rzeczach planowanych do włączenia w Linuksie 2.6.22, parawirtualizacji Lguest i Xen, nowej implementacji stosu FireWire, nowej wersji drzewa -ck oraz krótki test planistów.

Miłej lektury!

1 Plany włączenia różnych rzeczy z -mm do 2.6.22

Andrew Morton wysłał na LKML listę łatek, które według niego są gotowe do włączenia do drzewa Linusa, lub z różnych powodów jeszcze się do tego nie nadają.
„[..]
* Wiadomość wysyłam również do linux-mm – sytuacja zarządzania pamięcią jest skomplikowana.
* Średnia stabilność ostatnich -mm nie była szczególnie wysoka, a niestety zabrakło czasu na znalezienie wszystkich błędów. Nie powinienem włączać wszystkich tych łatek w zeszłym tygodniu – zawierają niespotykaną ilość śmieci. To wszystko oznacza, że więcej niż zazwyczaj błędów przedostanie się do mainline i będziemy musieli je tam naprawić.
* Ostatnio unikałem łatek, które nie poprawiają błędów. Mam w przybliżeniu 200 łatek wprowadzających jakąś funkcjonalność lub porządkujących kod - ich włączenie rozważymy później.
[..]”

Dalsza dyskusja rozdzieliła się na wiele wątków, w których deweloperzy omawiali poszczególne zmiany.

2 Przybywa

Po omówieniu Wszystkich Ważnych Spraw (TM) Andrew wysłał podsumowanie zaplanowanych zmian: „A więc to jest to, co przygotowałem na pierwszą serię mm->2.6.22. Nie będę tego wysyłał przez najbliższe 12-24 godziny, aby dać ludziom czas na ostatnie komentarze i sobie czas na sprawdzenie czy to działa.

* Kilka bitów serial.
* Kilka bitów pcmcia.
* Trochę rzeczy z kolejki MM (Memory Management - zarządzanie pamięcią):
* Rozszerzenia do /proc/pid/smaps pozwalające na monitorowanie stron pamięci przydzielonych dla procesu. Jest jeszcze jedna seria łatek od Matta Mackalla, która się opiera na tych zmianach, ale nie jest jeszcze wystarczająco gotowa.
* Alokator SLUB. Jest jeszcze nowy, ale chcę popchnąć to do przodu, aby w przyszłości zastąpić alokator plastrowy. Jeśli skończy się na tym, że nie będzie działać, to powinniśmy usunąć alokator SLUB ponownie. Jednak wątpię w to, żeby tak się stało. Jeżeli SLUB nie będzie w wystarczająco dobrym kształcie dla 2.6.22, to powinniśmy ukryć go w Kconfig, aby przestrzec ludzi przed napotykaniem znanych problemów – zostanie jako EXPERIMENTAL.
* generic pagetable quicklist management. Mamy implementacje dla x86_64, ia64 i sparc64, ale na razie włączę tylko implementacje Davida dla sparc64. Implementacje x86_64 i ia64 zostaną wysłane przez opiekunów architektur.
* Różne losowe zmiany w MM
* Zmiany w teach-get_unmapped_area-about-MAP_FIXED
* madvise(MADV_FREE)

To oznacza, że wstrzymuje zmiany Mela w alokatorze stron oraz lumpy-reclaim Andiego.

Wstyd – miałem wielkie nadzieję na lumpy reclaim w przeciwieństwie do moveable zone, ale tych rzeczy nie da się łatwo zrobić.

Kilka zmian MM zostało wstrzymanych i czeka na włączenie drzew podsystemów (prawdopodobnie x86 – nie sprawdzałem)

* Jedna mała poprawka bezpieczeństwa
* Architektura blackfin
* Mała aktualizacja h8300
* Mała aktualizacja alpha
* Aktualizacje swsusp
* Bity m68k
* Aktualizacje cris
* Dużo poprawek UML
* v850, xtensa"

3 Lguest dla 2.6.21

Rusty Russel powiadomił o wydaniu najnowszej wersji swojego hypervisora dla stabilnego jądra 2.6.21: „Lguest jest prostym monitorem maszyny wirtualnej, który uruchamia Linuksa pod Linuksem, bez potrzeby korzystania ze sprzętu z technologią VT.

Dwoje ludzi zapytało się mnie, czy mam wersję lguesta pracującą na jądrach innych niż najnowsze-bleeding-edge-mm, więc zrobiłem backport najnowszej wersji do 2.6.21.

http://lguest.ozlabs.org/lguest-2.6.21-254.patch.gz

Zajrzyj do Documentation/lguest/lguest.txt, aby dowiedzieć się jak to uruchomić. W drivers/lguest/README znajdziesz dokumentacje kodu źródłowego.

Raporty błędów i sukcesów zawsze mile widziane!

Szybki start:

$ cd linux-2.6.21
$ zcat /tmp/lguest-2.6.21-254.patch.gz | patch -p1
$ make
        - Odpowiedz "y" na CONFIG_EXPERIMENTAL, "m" na CONFIG_LGUEST.
$ make modules_install
$ make -C Documentation/lguest
$ sudo Documentation/lguest/lguest --block=<some-convenient-raw-image> \
        128 vmlinux root=/dev/lgba

Trzy ^C w ciągu sekundy zabiją klienta.”

WANG Cong znalazł dwa błędy w kodzie Lguesta i wysłał Rustemu łatki, następnie dyskusja zeszła na temat nieszkodliwych ostrzeżeń gcc podczas kompilacji kodu hypervisora.

Matt Mackall zwrócił Russellowi uwagę na brak dokumentacji związanej z konfiguracją systemu, który działa jako klient. Rusty odpowiedział: „To przez to, że to dokładnie takie same jądra. Włączenie CONFIG_LGUEST wbudowuje wszystkie funkcje potrzebne do działania jako system klienta.”

4 2.6.21-ck1

Con Kolivas napisał: „Ten zestaw łatek jest zaprojektowany tak, aby polepszyć interaktywność systemu i jego czas reakcji. Jest konfigurowalny dla wszystkich obciążeń, domyślna wersja -ck jest przeznaczona dla desktopów a wersja -cks dla serwerów.

Aplikuje się na 2.6.21
http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.21/2.6.21-ck1/patch-2.6.21-ck1.bz2

lub wersja serwerowa
http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.21/2.6.21-ck1/patch-2.6.21-cks1.bz2

strona web:
http://kernel.kolivas.org

wiki:
http://ck.wikia.com

wszystkie łatki:
http://www.kernel.org/pub/linux/kernel/people/ck/patches/

Zmiany od 2.6.20-ck1:

Planista staircase-deadline zastąpił w tej wersji starą wersję planisty staircase. Dodatkowe polityki szeregowania z 2.6.20-ck1 - SCHED_IDLEPRIO
(szeregowanie przy bezczynnym CPU) i SCHED_ISO (nieuprzywilejowany soft real time) zostały przepisane i działają tak samo z nowym planistą. W większości wypadków nie powinno być żadnych problemów z zastąpieniem starszych wersji -ck, poza porzuceniem „compute” żadne zmiany w przestrzeni użytkownika nie muszą być wprowadzone.

Do tego jądra zostało dodanych więcej opcji HZ. Otrzymałem wiele próśb w tej sprawie. Ponieważ dodanie nowych wartości nie jest trudne postanowiłem wprowadzić wartości aż do 10000 HZ (w większości bez wsparcia technicznego). Jeśli dobrze pamiętam, to niektórzy ludzie zauważyli, że serwery gier działają lepiej przy wartościach do 4000. Niestety ta łatka nie aplikuje się czysto na 2.6.21.1, więc jeśli chcesz zaaplikować ją na to jądro, to zignoruj komunikaty o błędach przy aplikowaniu lub zrezygnuj z łatki hz-raise_max-2.patch.
[..]
Poszczególne łatki:
http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.21/2.6.21-ck1/patches/ "

David J. Wallace napisał: „Używam 2.6.21-ck1 z powodzeniem na różnych maszynach i wszystko wydaje się być ok zarówno na sprzęcie jedno procesorowym jak i SMP.

Używam SD (staircase-deadline) od kilku tygodni, od tygodnia na zmianę ze „starym” planistą staircase. SD wydaje się działać bardzo płynnie, gdy wracam do używania starego planisty, już nie mam takiego odczucia. Nie robię benchmarków, „odczucie” bardziej się dla mnie liczy. Aktualnie mogę powiedzieć, że mój R4 działa lepiej z SD. Dobra robota.[..]”

Miguel Figueiredo napisał: „Używam tej łatki po raz pierwszy i piszę co zauważyłem.

Przed tą łatką z wszystkimi programami jakie mam zazwyczaj uruchomione (opera/iceweasel z dużą ilością zakładek, icedove, konversation, akregator, klient second life, vim i inne) czas odpowiedzi był niski (oczekiwanie na odpowiedź programu, odrysowanie okna – szczególnie podczas przełączania wirtualnych pulpitów).

Gdy zacząłem używać tej wersji, interaktywność/czas odpowiedzi wydają się poprawione, nigdy nie używałem Linuksa z tak niskim czasem odpowiedzi. Mogę zmieniać wirtualne pulpity i od razu widzę efekt zmian. Nawet przy obciążeniu 2.0 system wydaje się działać szybko, audio i wideo działają bez żadnych zacięć.”

5 Nowy stos FireWire

Kristian Høgsberg poprosił Linusa o włączenie nowego stosu FireWire do jądra
„Jak już możesz wiedzieć, na linux1394-devel pracowaliśmy nad nowym stosem FireWire. Głównym celem tego wszystkiego było otrzymanie małego, łatwego do utrzymania i opieki stosu FireWire wstecznie kompatybilnego.

Rozmawiałem ze Stefanem Richterem i uważamy, że nowy stos jest gotowy do włączenia. Chciałbym zaproponować, żeby przez kilka wydań w jądrze był zarówno nowy jak i stary stos. Gdy osiągniemy satysfakcjonujący poziom stabilności i pozbędziemy się znalezionych błędów, to możemy rozważyć usunięcie starego stosu. Utrzymywanie dwóch wersji stosu FireWire w jądrze nie jest idealnym rozwiązaniem, ale pozwoli to na szersze przetestowanie nowej wersji, a po napotkaniu większych problemów, zawsze będzie można wrócić do poprzedniej.

Jest dużo dobrych powodów do przejścia na nowy stos i dużo powodów do porzucenia starego. Najważniejsze:

  • Był w Fedora rawhide (gałąź rozwojowa) i -mm przez 3 miesiące, będzie w Fedorze 7.
  • Kompatybilność wsteczna na poziomie bibliotek; istniejące biblioteki w przestrzeni użytkownika zostały przeportowane na nowy interfejs.
  • Mniej niż 8 tysięcy linii kodu w porównaniu do 30 tysięcy linii kodu starego stosu - podobna redukcja rozmiaru modułów.
  • Brak wątków jądra w porównaniu do jednego wątku na podsystem i każdy kontroler FireWire w starym stosie.
  • Jeden interfejs dla przestrzeni użytkownika dla wsparcia streamingu w przeciwieństwie do 4 (było 5) różnych w starym stosie.
  • Pliki urządzeń dla każdego urządzenia, pozwala na większą kontrolę dostępu w przestrzeni użytkownika np. zabronienie bezpośredniego dostępu do urządzeń składowania danych.

Regresje:

  • eth1394 jeszcze nie jest przeportowane. Nic nie stoi na przeszkodzie w wykonaniu tego, ale jeszcze brakuje kilku rzeczy w infrastrukturze.
  • Brak wsparcia dla chipsetu PCILynx. Nikt go już nie ma, a sterownik pcilynx w starym stosie nie działa za dobrze.
  • Niektóre urządzenia SBP-2 (storage) zawodzą po znacznej ilości operacji IO. Nie jest jasne w czym leży problem, ale mogę go odtworzyć i już pracuje nad jego naprawieniem.”

Christoph Hellwig poprosił Kristiana o wcześniejsze wysłanie łatek, aby można było je przejrzeć. Dalsza dyskusja skupiła się na wyszukiwaniu problemów w implementacji nowego stosu.

6 Xen - implementacja dla paravirt_ops

Jeremy Fitzhardinge wysłał serię łatek implementujących interfejs paravirt-ops w Xen.
„Seria nakłada się na 2.6.21-git3 + ff patches-2.6.21-git3-070501-1.tar.gz.

Zmiany od ostatniego wysłania:
* przejrzenie xenbus (ja) netfront (hch, rusty, herbert xu) i blockfront (hch), większość uwag została uwzględniona. Przegląd Netfront ujawnił kilka poważnych błędów, kod wszystkich trzech wygląda teraz lepiej.
* łatki poprawiające błędy zostały włączone do głównych łatek
* dużo poprawek stylu kodowania oraz innych usprawnień

Może wystąpić mały konflikt w xen-hvc-console spowodowany lguest console.

Te łatki są już całkiem dobrze przetestowane, z kilkoma zakończonymi sukcesem testami na XenSource regression test suite. Na razie nie używałbym jądra z xen/paravirt_ops w środowisku produkcyjnym, jednak wydaje się całkiem funkcjonalne.

Ta seria jest ogólnie ograniczona do zmian specyficznych dla Xen, jednak w kilku miejscach wprowadza kilka małych zmian.

Włącza:
* pliki nagłówkowe interfejsów Xen
* implementacja rdzenia Xen
* skuteczny late-pinning/early-unpinning pagetable handling
* wirtualizacja czasu, włączając skradziony czas
* wsparcie dla SMP
* wsparcie dla wywłaszczenia
* Batched pagetable updates
* Xen console, bazuje na hvc console
* Xenbus
* Netfront, parawirtualizowane urządzenia sieciowe.
* Blockfront, parawirtualizowane urządzenia blokowe”

6 CFS v9 vs SD 0.48

Od pewnego czasu na LKML trwa mała wojenka planistów zadań, od czasu do czasu wielbiciele jednego planisty podsyłają benchmarki, aby drugiej stronie szczęki poopadały. Używają przy tym specjalnie zaprojektowanych programów, które dobrze działają tylko na jednym planiście, a użyte do testowania drugiego pokazują jego słabe strony. Ragnvald Maartmann-Moe IV podesłał wyniki sowich testów - nie robionych profesjonalnie (i wiele można byłoby temu zarzucić) ale przynajmniej obiekty testów były prawdziwymi aplikacjami 3d (to był chyba najbardziej zapalny punkt wcześniej wspomnianej wojenki).

„[..] Dodatkowe funkcje CK nie powinny mieć znaczenia, większość testów jest uruchamianych na nieobciążonym systemie.

Zacznijmy od benchmarków gier.

** Doom 3 uruchomiony przy rozdzielczości 640*480@60Hz z ustawieniami własnymi zbliżonymi do najwyższych możliwych. QuakeForge uruchomiony przy rozdzielczości 1680x1050@60Hz przy maksymalnych ustawieniach jakościowych i zastąpionymi standardowymi teksturami (http://facelift.quakedev.com/retexture) **

doom 3 demo1 QF overkill
-cfs9 X -10 66.9 fps 181.7 fps +-0.040 fps
-cfs9 X 0 67.6 fps 181.5 fps +-0.025 fps
-ck1 X -10 67.1 fps 182.1 fps +-0.063 fps
-ck1 X 0 67.9 fps 182.5 fps +-0.094 fps

Średnia jest wyliczana na podstawie pięciu testów, najniższy i najwyższy wynik jest odrzucany, średnia jest obliczana z trzech pozostałych. Odstępstwo: Wyniki Doom 3 były ekstremalnie zmienne na CFS v9 i X na poziomie nice -10, i cechowały się paskudną średnią na poziomie 64 fps. Więc wynik Doom 3 na X -10 był obliczany z 9 testów, najwyższy i najniższy wynik zostały odrzucone, średnia została policzona z 7 wyników.

Oba schedulery są odporne na zatrzymania odgrywania muzyki podczas kompilacji.

Według mnie zmiana poziomu nice pod CFS jest niebezpieczna. Bardzo łatwo można osiągnąć olbrzymie opóźnienia. Podczas wspomnianej wcześniej kompilacji, poruszania wskaźnikiem myszki i pisania, łatwo można zaobserwować, że tekst pojawia się dopiero po 4-5 sekundach (lub w ogóle się nie pojawia) na CFS z poziomem nice X -10. Wszystko inne jest uruchomione z niezmienionymi priorytetami. CFS bez zmienionych poziomów nice jest lepszy niż standardowy planista w Linuksie, ale ciągle ma małe opóźnienia podczas poruszania kursorem myszki.

SD, który ma mniejsze opóźnienia w odrysowywaniu okien, sytuacja poprawia się po zmianie poziomu nice dla X na -10. Poza tym nie dostajemy kary za zmianę poziomu nice. Jednak zmniejszenie opóźnień nie jest tak duże jak na starszych wersjach SD.

Najgorszym testem dla CFS są gry uruchomione pod wine. Diablo II: Lord of Destruction uruchomiony pod winehq 0.9.36 nie gubi już dźwięku, jak to się działo na poprzednich wersjach CFS… zamiast tego zacina się renderowanie scen przy większych walkach.

Guild Wars pod Cedegą (niegrywalny na wine) na CFS strasznie się zacina podczas akcji, podczas normalnej gry zachowuje się nieprzewidywalnie. Muzyka czasami nie działa.

Diablo2 i GW działają bardzo płynnie na SD, bez żadnych zacięć muzyki. Nie miałem żadnych problemów z audio w 2.6.21-ck1, nawet gdy rozmyślnie chciałem je sprowokować. Jeszcze nie uciekałem się do równoległego make z ujemnymi parametrami nice.

Mój system to 754 Athlon 64 3000+, 1GB PC3200, płyta główna NForce3 250, GF6800GT ze sterownikami Nvidia 100.14.03 beta. Używam CFQ i libata dla mich dysków twardych. Ubuntu x86_64 Gutsy Gibbon z 32bitowym chroot dla starszych gier.

Na 10 stopniowej skali, SD dałbym 9, Windowsowi w przybliżeniu 6, CFS 5, standardowemu linuksowemu planiście 3 (w zeszłym roku było tylko 1), za interaktywność i obsługę obciążeń. Używam Linuksa od lat przez jego wydajność, jednak latencja UI, ani odporność na opóźnienia audio nigdy nie była jego silną stroną. Do teraz. SD wygrywa we wszystkim, co przetestowałem.”

Ten numer KWN został przygotowany przez Michała Piotrowskiego.

O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-Share Alike 2.5 License.