Kernel Traffic #141 For 12 Nov 2001

Ponieważ w MM w jądrach Linusa znikły listy niekaktywnych brudnych/czystych stron na rzecz jednej listy nieaktywnych stron, program musiał być poprawiony tak, aby to obsługiwać.

Cały czas możecie używać starszej wersji dla jąder <= 2.4.9 i/lub jąder Alana (-ac), które cały czas używają starszego podsystemu VM Rika.

MM uspokoiło się, ale OOM killer nie działał. W tej chwili działa i używa tak prostych heurystyk, że to aż wstyd.

I wątpię, aby komuś udało się naruszyć owe heurystyki OOM -- nie uaktywaniając ich, gdy potrzeba, bądź uaktywniając zbyt wcześnie. Zostaniecie nagrodzeni uściskiem dłoni prezesa jeśli się to Wam uda i powiecie mi jak (,,Uścisk dłoni prezesa''? Tak, jestem tandeciarzem. Ale to nic nowego.)

_Naprawdę_ jestem ciekaw, czy przy jakimkolwiek obciążeniu VM można zaobserwować złe zachowanie. Jeśli macie jakieś zastrzeżenia do VM, to teraz jest pora na ich ujawnienie. W innym przypadku, uważam, że jest gotów.

Mój nie-taki-znowu-przebiegły plan przewiduje w tej chwili znalezienie dużych problemów, wypuszczenie rozsądnego 2.4.14 i chwilowe zatrzymanie połączone z odmową włączania nowych rzeczy.

Dalej, 2.4.15 byłby miejscem, gdzie zacznę 2.5.x, i gdzie Alan zacznie robić, co tylko mu się podoba z 2.4.x. Włączając w to, oczywiście, odwrócenie wszystkich moich i Andrei zmian w VM ;)

Osobiście jestem przekonany, że w moim drzewie dokonują się dobre rzeczy odnośnie VM, ale Alan _będzie_ opiekunem, a ja nie zamierzam wpływać na jego decyzje. Ostatnią rzeczą, którą chciałbym robić, jest bycie mikrozarządzającym krawaciarzem.

(2.5.x z pewnością będzie używać nowego VM i wierzę, że nowy VM jest lepszy. Sądzę, że Alan w koñcu ujrzy światełko, ale w tym samym miejscu przyznaję, że Alan miał rację odnośnie kwestii stabilności w ciągu ostatniego miesiąca, czy dwóch ;)

Ludzie zastanawiają się nad postępami prac nad stabilnym jądrem 2.4. Różne dziwaczne plotki z Byte spowodowały całą lawinę dyskusji i plotek. W tej chwili wszyscy zainteresowani są zgodni, że należy przedstawić jakiś plan działania, aby te plotki rozwiać.

Linus wkrótce wypuści 2.4.14 i przypuszczalnie wersją 2.4.15 zakoñczy prace nad stabilnością VM i innymi takimi rzeczami. W tym momencie rozpocznie się rozwój drzewa 2.5. Jest wiele spraw zaplanowanych na 2.5. Nie jest ani możliwe, ani sensowne wrzucać je wszystkie do 2.5.0. Jednym z zadañ jest wykonanie wszystkich zmian we właściwej kolejności.

Marcelo Tosatti będzie głównym opiekunem stabilnego drzewa 2.4. Nie jest to taka duża zmiana, jak mogłoby się wydawać z zewnątrz. Opieka nad stabilnym jądrem była i jest pracą grupową. Marcelo i wiele innych osób czynnie brało udział w stabilizacji jąder 2.2 i 2.4. Będę służył mu radą, gdy tylko mnie o to poprosi oraz będę pracował nad podsyłaniem mu odpowiednich fragmentów z drzewa -ac.

Nie zniknę ze sceny, ale być może będę trochę mniej widoczny. Jest wiele różnych projektów związanych z jądrem Linuksa, nad którymi pracuję, a także będe spędzał więcej czasu na zaspokajaniu potrzeb klientów Red Hata. Sądzę, że spędzanie większej ilości czasu z klientami pomoże ustalić kierunek, w którym 2.5 powinno się rozwijać.

David Weinehall znakomicie się spisał przy 2.0.39, gdy przejął 2.0 ode mnie. Jestem przekonany, że Marcelo da sobie radę z 2.4.

We wcześniejszej wiadomości pokazałem, jak łatwo i powtarzalnie zablokować mój vm, ale od tego czasu zostało to już w jakiś sposób poprawione. Powtórzyłem test i wziąłem vmstat 1 z obu jąder, które badałem: 2.4.14-pre6-preempt i 2.4.13-ac5-preempt. Uruchomiłem oba vmstaty w tym samym momencie (około 4 sekund przed rozpoczęciem testów). To, co zrobiłem, to uruchomienie kghostview na pliku postscriptowym dostępnym tu: http://safemode.homeip.net/test.ps. Zajmuje 224K. kmail był już wcześniej załadowany w obu testach, więc kdeinit był już w pamięci, tak jak i inne biblioteki. Gdy kghostwiew zaczął odpowiadać, odczekałem kilka sekund (ponownie około 5) i zamknąłem aplikację.

Żadna inna interakcja nie była dokonywana, ani żaden inny program nie działał podczas wykonywania testu. Mam 771580 KB RAM-u oraz 290740 KB swapu.

Teraz objaśnię wykresy. Niebieski to vm AA. Czerwony to vm Rika. vm Rika zakoñczył pracę po 66 sekundach. vm Andrei zakoñczył pracę po 52 sekundach. Żaden z nich nie dotknął swapa.

Tu jest wykres http://safemode.homeip.net/vm_swapcomparison.png. Zajmuje około 4.6K.

Gdy popatrzycie na wykres, przedstawia się on następująco. Po lewej stronie jest 0 sekund, po prawej stronie jest 66 sekund. na dole jest 0KB, na górze jest 290740KB.

A tu są oryginalne wyniki wygenerowane przez vmstat. Są dostępne pod adresem: http://safemode.homeip.net/aa_vmstat i http://safemode.homeip.net/rik_vmstat

Szczegółową interpretację wyników i wykresów zostawię tym, którzy dokładnie znają kod.

Dodam jedynie, że podczas przeprowadzania testu, cały komputer po kilka razy przestawał odpowiadać na dłuższy okres czasu i to przy obu jądrach. Nie był wygenerowany żaden OOM.

Sądzę, że odpowiedź na pytanie, dlaczego jądro AA pobiło jądro rika, nie ma nic do tego, ile swapu używa rik, czy ile swapu zostało z powrotem umieszczone w pamięci. Chodzi raczej o to, jak rik wybiera to, co swapować. Mówiąc dokładniej, algorym wykorzystywany przez rika do zabawy z pamięcią zużywa zdecydowanie za dużo czasu procesora i zostawia go zbyt mało dla właściwego procesu. W odróżnieniu od tego, kod AA, który mniej obciąża cpu, pozwala programowi naprawdę działać i dlatego, pomimo popełniania błedów przy decyzjach, co wyswapować, proces koñczy się dużo szybciej niż w przypadku inteligentnego kodu Rika.

Niestety, ostatnie kolumny z wyniku działania vmstat na aa jakimś cudem zniknęły podczas kopiowania z buforu terminala do pliku. To oznacza, że będę musiał wykonać to wszystko jeszcze raz tak, aby dostać porównywalne wyniki zyżycia cpu w stosunku do vm rika. Ale w tej chwili sądzę, że wykres vm rika jest wystarczający. I jest kilka danych w wyniku vmstat AA, które także wskazują na niższe zużycie procesora niż u rika. O WIELE.

Nałożyłem wykorzystanie procesora przez jądro Rika na wykresy so i si, aby to zobrazować. Na dole obciążenie jest 0%, na górze -- 100%.

http://safemode.homeip.net/sys_so.png

Możemy zauważyć, że po każdym większym zapisie następuje duże zużycie procesora. To jest poważne użycie i to jest powód, dla którego VM rika przegrywa wyścig, nawet jeśli swapowało w tę i z powrotem właściwsze rzeczy niż VM AA.

http://safemode.homeip.net/sys_si.png

Oczywiście po każdym większym zapisie w vm Rika następuje mniejszy odczyt. To się dzieje dokładnie przy taktach cpu, więc być może to jest przyczyną wysokiego zużycia cpu, przy okazji określania, gdzie jest strona. Nie wiem dostatecznie wiele, co się dzieje w kodzie, aby stwierdzić, czy VM po zapisie bądź odczycie wykonuje coś, co mogłoby wykorzystywać całą moc procesora. Po bliższym przyjrzeniu się zjawisku, skłaniam się ku stanowisku, że problemy powoduje jakiś błędny kod działający na granicy swap -> ram.

To jest przykład na to, dlaczego prosta architektura vm może być lepsza niż złożona. Mniej czasu procesora zużytego na operacje w jądrze oznacza więcej czasu procesora dla programu, i czasami czas zaszczędzony na małym zapotrzebowaniu na procesor, daje o wiele więcej niż czas stracony na poprawianiu błędów przy decyzjach, które strony przemieszczać pomiędzy swapem i pamięcią RAM.

Być może mylę się co do przyczyny zużycia procesora przez jądro, ale wyniki, które uzyskałem przy vmstacie na AA, są znacznie lepsze niż te w jądrze Rika. To i fakt, że vm Rika wydaje się robić prawidłowe rzeczy, podczas gdy w kodzie Andrei przechodzi się do porządku dziennego nad pomyłkami, a poprawiając te pomyłki Rik traci, wskazują na to, że mam rację wskazując na zużycie procesora przez vm, jako na główny problem w VM Rika.

Zauważ, że to jest bardzo prawdopodobny efekt uboczny sytuacji, gdy brakuje swapu, ponieważ wiele ,,oczywistych kandydatów'' do umieszczenia w swapie, nie może być tam umieszczonych, co oznacza, że trzeba przejrzeć więcej stron zanim nie znajdziemy czegoś, co już zostało umieszczone w swapie.

Zanim wyciągniesz wnioski takie, jak przedstawiłeś powyżej, proszę przetestuj to jeszcze raz z większą ilością swapu.

Uhhh ... to nic innego niż klasyczna równowaga pomiędzy szybkością a rozmiarem.

Fakt, że przy moim VM przestrzeñ swap pozostaje zarezerwowana przez program przy swapowaniu oznacza, że jeśli strona nie jest oznaczona jako brudna, możemy ją po prostu wyrzucić bez ponownego zapisywania na dysk.

W sytuacjach, gdy jest dostępne wystarczająco dużo swapu, to powinno dawać zysk (i zazwyczaj dawało duży zysk).

VM Andrei zawsze zwalnia przestrzeñ swapu przy swapowaniu, więc nawet jeśli proces w ogóle nic nie zapisze do swojej pamięci, dane muszą zostać ponownie zapisane na dysk.

Jedynie w podbramkowej sytacji, gdy mojemu VM brakuje miejsca w swapie, a VM Andrei ma jeszcze trochę swapu, będziesz miał sytuację, gdy taktyka stosowana przez VM Andrei ma przewagę, ale sądzę, że jest to bardzo rzadka sytuacja.

Solaris 9/ia32 zawiera oprogramowanie lxrun (dołączone do Solarisa 8, którego Sun, z jakiegoś durnego powodu, tak lubi), które implementuje ABI z Linuksa/ia32 na Solarisie/ia32. Jest to coś podobnego do warstwy kompatybilności z Linuksem, którą posiadają teraz wszystkie systemy *BSD.

Solaris 9 zarówno na platformie Intel, jak i na Sparc, implementuje więcej Linuksowych (a tak naprawdę GNU glibcowych) API. Przyświeca temu idea, iż aplikacje Linuksowe wystarczy teraz tylko przekompilować, aby uruchomić je na Solarisie (zakładając, że są dobrze napisane i nie mają do rozwiązania zagadnieñ typu 32-/64-bitowość, czy kolejność bitów w bajcie), bez konieczności ich portowania.

Wydaje mi się, że te dwie właściwości są odbiciem tej linii. Kradzież kodu nie miała miejsca, a Solaris zdecydowanie nie jest zgodny z GPL.

Śledzę sprawy związane z VM w 2.4 od wczesnych czasów tej serii. Jako ,,silny użytkownik'' i ktoś, kto używa Linuksa w pracy, stabilność jądra interesuje mnie niezmiernie. Wreszcie miałem już dość prób interpretowania danych z różnych źródeł na temat wydajności systemów VM w 2.4, oraz porównywania jednych i drugich rozwiązañ. Poczyniłem więc swoje własne testy na jądrach 2.4.12-ac6, 2.4.13 oraz 2.2.19 i spisałem ich wyniki:

,,Analiza trzech systemów VM w jądrach Linuksa''

http://www.nks.net/linux-vm.html

Najkrótszym podsumowaniem jest: tak, systemy VM w jądrach 2.4 wciąż mają kilka błędów, które należy rozwiązać, ale ogólnie są tak znacząco lepsze od tych z serii 2.2, iż nie można ich tak naprawdę porównywać.

Jednak, konkluzja ,,znacząco lepsze'' stosuje sie do niektórych mocno ,,stresujących'' sytuacji, kiedy VM z 2.2 zawodzi na całej linii, a ta z 2.4 przełyka obciążenie praktycznie bez szwanku.

W ogólnych odczuciach zwykłego użytkownika, 2.2 wciąż sprawuje się lepiej ze względu na interaktywną reakcję przy różnych obciążeniach, mimo iż 2.4 jest tak naprawdę szybsze przy wykonywaniu danych zadañ.

Parę osób wyraziło życzenie zastąpienia alokatora bazującego na bitmapach bootmem, takim, który bezpośrednio śledzi zakresy. Napisałem taki zamiennik, by uporać się z niektórymi sytuacjami, które mnie spotykały.

Następująca łata dotyczy zużycia tylko pamięci proporcjonalnej do liczby oddzielnych fragmentów pamięci, śledząc dostępną pamięć i rozdrobnienie adresów aż do miejsca inicjalizacji struktur danych dla każdej strony, a potem używając drzewa segmentów w celu obsługi efektywnego wyszukiwania na tych rzadko spotykanych maszynach, na których jest to problem. Testy pokazują, że łata wydaje się oszczędzać między 8KB i 2MB na i386 PC w porównaniu do opartego na bitmapie alokatora bootmem.

Następująca łata była testowana na sprzęcie i386 PC, IA64 Lions i IBM IA64 NUMA, z rzadką pamięcią i debugowana bez pomocy analizatorów logicznych lub specjalnych sond. Chciałbym podziękować testerom z #kernelnewbies (retluk i asalib) i moim współpracownikom za ich pomoc w wykonaniu tej pracy, oraz Tony'emu Luckowi i Jackowi Steinerowi za ich towarzyszenie przy dostosowywaniu istniejącego bootmem.

Teraz jestem szczególnie zainteresowany oceną projektu oraz wynikami szerszych testów.

To uaktualnienie głównie poprawia błąd, który pojawiał się z prawdopodobieñstwem jeden do miliona w nietestowanym przypadku. Ten błąd objawiał się tym, że rm -rf usuwało wszystkie pliki z wyjątkiem jednego, w katalogu zawierającym milion plików. Mam nadzieję, że jest to ostatnia nieprzetestowana możliwość i gdyby nie ona, łata byłaba już stabilna.

Nie spodziewałem się, że highmem będzie dobrze działać i nie działało. Jest na mojej liście rzeczy do zrobienia, ale narazie higmem musi być wyłączone, bo w przeciwnym wypadku dostajesz oopsa przy starcie.

Wyprodukowałem także wyrzucanie informacji dx_show_buckets, żeby móc śledzić błędy i pokazać całe drzewo indeksowe zamiast jednego poziomu. Funkcja ta służy teraz jako zwarte podsumowanie struktury drzewa indeksu i, o czym można się samemu przekonać, jest prosta.

Wykonałem trochę dodatkowych testów, włączając w to testy wydajnościowe na prawdziwych maszynach i stwierdziłem, że wszystko działa w miarę dobrze dla około 2 milionów plików, w czasie około 50 mikrosekund na jedno utworzenie pliku i 300 mikrosekund na skasowanie (1 GHz PIII). Przy 4 milionach plików robi się troszkę gruszkowato, ale wierzę, że to nie przez łatę indeksującą, tylko przez rd. Wszystko się udaje, ale wymaga wykładniczo więcej czasu przy 98% bezczynności procesora i przekładaniu bloków w zakresie 300 sekund. Spojrzę na to później.

Niespodziewanie trafiłem na złe zachowanie mm w 2.4.13. Wydaje się, że icache jest zbyt surowo dławione, co powoduje, że wydajność usuwania jest niższa niż powinna być. Zauważyłem też, że czasem, pracując na uml (2.4.13), nie mogę stworzyć miliona plików testowych w dostępnej pamięci (bez oom). Doświadczenie podpowiada mi, że takie problemy nie powstają z winy umla, ale raczej z winy fragmentu jądra zarządzającego pamięcią. Być może nie dotyczy to najnowszych jąder pre, ale wydaje się, że jest jeszcze sporo możliwości na poprawienie stabilności mm.

Łatka jest dostępna pod adresem:

http://nl.linux.org/~phillips/htree/ext2.index-2.4.13-2

Muszę przyznać, że pierwsze wrażenie jest rzeczywiście bardzo dobre.

Wziąłem rzeczywisty katalog, którego normalnie używam (folder MH zawierający około 115000 plików) i zrobiłem w nim 'du -s'.

Bez łaty zabrało to trochę więcej niż 20 minut.

Z łatą zmieściło się w mniej niż 20 sekundach. (I było to w uml)

Ted Ts'o zgłosił się na ochotnika do zrobienia tego, ale ja nawaliłem, bo nie wspomogłem go właściwą dokumentacją, więc jest to jeszcze nie zrobione.

Jednakże jest dość łatwo to obejść, wystarczy wykomentować część łaty, która ustawia flagę incompact. Wtedy poindeksowane katalogi magicznie zamienią się z powrotem w normalne przy następnym pisaniu do nich (byłoby dobrze dać taką opcję do testów na używanych katalogach :-)

Nie mówię, że Linus powinien wykonywać testy.

To dobrze, że Linus prosi innych o testowanie, jak to zrobił na http://marc.theaimsgroup.com/?l=linux-kernel&m=100451768023436&w=2

Byłoby nawet lepiej, gdyby Linus ogłosił, że odmówi nazwania jądra finalnym jeśli będzie jakikolwiek aktualny raport o błędzie w nim, pojawiający się w czasie ustalonych testów wydajnościowych.

A byłoby *jeszcze lepiej*, jeśli do wykonywania testów wydajnościowych jąder, które mają zostać wypuszczone, używane by było http://osdl.org/stp/, w przyjemny, zautomatyzowany sposób na maszynach 1, 4, 8 i 16 procesorowych.

Prawie nic z tego nie wymaga żadnej pracy od Linusa. Wszystko, co Linus musi zrobić, to powiedzieć ,,Jądra 2.4.x będą przechodziły testy wydajności przed wypuszczeniem'' i wybrać kogoś do przepuszczania tych jąder przez STP OSDLa w odpowiednim czasie.

Szczegóły na temat możliwości ściągnięcia oraz dokumentacja znajdują się pod adresem:

http://www.uow.edu.au/~andrewm/linux/ext3/

Zmiany w stosunku do ext3-0.9.13 (które było łatą na linuksa 2.4.13):

• Naprawiono oopsa informującego o odwołaniu się do niezaalokowanej komórki pamięci, który mógł się pojawiać na maszynach z SMP. Poprawka była zaaplikowana do 2.4.12-ac6, ale nikt nie zgłaszał nigdy oopsa w jądrach -ac.
• Usunięto dużo kodu, który służył tylko deweloperom. Będzie od teraz oddzielnie utrzymywany.
• Jest pewien konfilkt w interakcji ext3 i bieżącymi łatami Extended Attributes i Access Control Lists, który prowadzi do padu systemu przy dużych obciążeniach na SMP. Być może pojawia się to na skutek drobnych zmian w API pomiędzy ext3 dla jąder 2.2, a wersją dla jąder 2.4 (tzn: zepsułem to). Na liście rzeczy do zrobienia.

• Przez długi czas łata ext3 używała semafora z głównego jądra, by zapobiec równoległemu zestronicowaniu i obcinaniu tego samego pliku. Tak było, by zapobiec przeplotowi, w którym zadanie zestronicowujące budziłoby się po obcięciu i tworzyłoby stronę w tablicy stron procesu, która miałaby dołączone bufory. To prowadzi do BUG() w kodzie wymieniającym, próbującym wymienić tę stronę.

  Ten semafor został usunięty. Zmieniono kod wymiany tak, że strony takie są wykrywane i ignorowane.

  To jest niewiarygodnie niejasna i trudna do rozwiązania sytuacja. Przypadek testowy, który zwykł ją wywoływać, nie jest w stanie dalej tego robić. Jeśli więc ktoś zobaczy informację "try_to_swap_out: page has buffers!", proszę głośno krzyczeć.

  Nie ma planów usunięcia tego semafora z jąder -ac, chyba że Alan będzie tego chciał.