Kernel Traffic #119 For 21 May 2001

Fakt opublikowania X15 powinien odsunąć oskarżenia pod adresem Linuksa, że jego niezwykłe wyniki w SPECweb99 wynikały jedynie z tego, że webserver działał w trybie jądra. Tak naprawdę to wysoka wydajność jądra 2.4 umożliwiła te wyniki. TUX był i zostanie poligonem do testowania wysoko wydajnego serwowania HTTP (i FTP), bez zbędnego narzutu na eksport API do trybu użytkownika.

[podejrzewam, że mała przewaga X15 jest wynikiem subtelnej różnicy w module SPECweb99 działającym w przestrzeni użytkownika: na przykład jakkolwiek TUX był napisany, testowany i gotowy do używania TUXAPI_alloc_read_objectbuf() z udostępnieniem mmap(), nie było to faktycznie umożliwione. Wysłałem do Fabio e-mail jak można to umożliwić, być może wykonał on jakieś testy które potwierdzą to podejrzenie?]

wykonując SPECweb99 benchmark dla TUX 2.0 z ostatnimi jądrami -ac wyszło mi, że 86% czasu procesora przypada na tryb jądra, nie związany z TUX-em , 12% odbywa się w przestrzeni użytkownika, w module SPECweb99, a tylko 2% przypada na tryb jądra związany z właściwym kodem TUX-a

po wykonaniu takiego samego testu z oryginalnym kodem TUX 1.0 okazało się, że więcej niż 50% czasu procesora zajęła część związana kodem TUX-a

co to oznacza? W ciągu około 6 miesięcy, odkąd wypuszczony został TUX 1.0, przesunęliśmy większość poprawek kodu TUX 1.0 do wewnętrznych części jądra (większość z nich umożliwiono także do wykonywania w przestrzeni użytkownika), a sam TUX stał się znacznie mniejszy (i zaczął używać coraz więcej ogólnych części jądra). W efekcie X15 wykonuje 50% kodu TUX-a :-)

(cały czas jest kilka łat, poprawiających wydajność i oczekujących na integrację z pozostałym kodem: pagecache extreme-scalability patch i smptimers patch. Łaty te przyspieszają zarówno TUX-a jak i X15.)

(jest jedna rzecz, która nigdy nie może zostać 'wyeksportowana do przestrzeni użytkownika': izolacja niepewnego kodu aplikacji z serwera bez utraty wydajności. Zawsze zatem musimy być otwarci na poprawność usług zawartych w jądrze.)

Linux 2.4 jest niewątpliwe jednym z najbardziej zaawansowanych systemów operacyjnych jakie w ogóle zostały stworzone, szczególnie z punktu widzenia optymalizacji oraz z powodu godnego podziwu oszczędności pomysłów na których jest oparty. Mam nadzieję, że X15 pomoże wzmocnić sukces tego niesamowitego systemu.

TUX oczywiście posłużył mi za pewien standard porównawczy wydajności w trakcie rozwijania X15, ale za inspirację dla architektury X15 posłużyło wiele źródeł. Najbardziej znaczącymi są Flash Web Server (Pai, Druschel, Zwaenepoel), kilka obserwacji Linusa na tej liście dotyczących architektury (web) serwerów i usług jądra oraz czytanie książek o architekturze autorstwa Hennessy & Pattersona. W koñcu, choć nie znaczy że jest to mniej ważne, obok gorących dyskusji, badanie architektury mikrokernela nauczyło nas jak uzyskiwać wydajny model interakcji pomiędzy różnymi przestrzeniami adresowymi.

Jeśli musiałbym zgadywać i wskazać co jest wąskim gardłem dla wydajności serwera HTTP, powiedziałbym, że leży ono gdzieś między podsystemem pamięci a szyną PCI.

Ze względu na istnienie przesyłania plików typu ,,zero-copy'', przesuwanie danych nie stanowi już problemu, asynchroniczne sieciowe wejście/wyjście pozwala na naprawdę niewiele kosztujący scheduling wątków, a wywołania systemowe dają niewielki narzut w Linuksie. To co zostało na teraz to wyeliminowanie sytuacji, w których procesor i karta sieciowa nieefektywnie walczą o pamięć albo o dostęp do szyny. Ciekawi mnie jak będzie traktowana sieć gdy będą dostępne szybsze maszyny.

Na mojej liście życzeñ dotyczących rozwoju jądra niewątpliwie umieściłbym asynchroniczne wejście/wyjście dyskowe oraz przyzwoitsza implementacja przekazywania deskryptorów pliku. Opiszę to w szczegółach w następnych listach.

Oczywiście sprawdzę wpływ łat Ingo na wydajność TUX-a w tym tygodniu.

Chciałbym także powtórzyć moją prośbę o pomoc w testowaniu X15 na serwerach o architekturze z ,,górnej półki''.

X15 jest ciągle bardzo młodym kodem w stadium alfa i jestem przekonany, że mogę poprawić jego wydajność na wiele sposobów.

Naszą intencją jest wypuszczenie X15 na licencji open source.

Stanie się to tak szybko jak szybko kod się trochę ustabilizuje, czyli wtedy kiedy będzie on w fazie beta (w ciągu dwóch - trzech tygodni).

W tej chwili po prostu nie mamy czasu...

Powodem wypuszczenia binarnej wersji alfa było to że parę ostów nie wierzyło, że serwer działający w przestrzeni użytkownika o tym poziomie wydajności jest w ogóle możliwy do zrealizowania

Poza tym, naprawdę doceniam odpowiedzi, które otrzymałem od Ingo i innych i bardzo chciałbym wiedzieć czy ktokolwiek w ogóle wykonał jakiekolwiek testy wydajności.

zauważyłem inną niezgodność X15 z RFC. Ignoruje on nagłówek żądania "Connection: close" przekazywany przez klienta zgodnego z HTTP/1.1. Takie zachowanie jest niezgodnie z RFC 2616, serwer nie może lekceważyć wyboru klienta, gdy ten chce mieć nie podtrzymywane (non-persistent) połączenie. (mogą istnieć klienci zgodni z HTTP/1.1, którzy nie wspierają połączeñ typu "persistent" i sygnalizują to przez "Connection: close".)

zasada jest taka: żądanie jest albo podtrzymywane (keepalive) albo nie podtrzymywane. Żądania HTTP/1.0 są domyślnie nie podtrzymywane. Żądania HTTP/1.1 są domyślnie podtrzymywane. Domyślne ustawienie może być zmienione przez "Connection: Keep-Alive" albo "Connection: close" w nagłówku.

jeśli to naprawisz, czy będzie to miało wpływ na wyniki SPECweb99 w jakikolwiek sposób?

zauważyłem jeszcze jedną anomalię. Nie wydaje się aby X15 właściwie dawało sobie radę z żądaniami potokowymi (pipline requests) protokołu HTTP/1.1, ignoruje ono drugie żądanie, jeśli przychodzą one w tym samym pakiecie.

SPECweb99 nie przysyła żądañ potokowych, ale robi to wiele klientów (Mozilla, apt-get, itp.)

Przygotowałem nową wersję X15, w której mam nadzieję rozwiązano wszystkie błędy niezgodności z RFC. Mam nadzieję, bo nie miałem możliwości pełnego testowania żądañ potokowych. Czy jest jakaś możliwość zautomatyzowania takich testów?

Pod względem tego, co udało mi się zmierzyć X15 jest wciąż 5% szybszy niż TUX.

Plik możesz znaleźć pod adresem: http://www.chromium.com/X15-Alpha-4.tgz

BTW: Następna wersja (powinna pojawić się mniej więcej w ciągu tygodnia) będzie wersją beta i będzie zawierała kod źródłowy!

Jestem ostrożny jeśli chodzi o używanie chipsetu Ali. Są one nawet mniej popularne niż VIA, więc problemy z nimi związane nie miały nawet szansy być rozwiązane

Najważniejszą cechą, której szukam w maszynie jest fakt posiadania 768 Meg albo 1G ram za rozsądną cenę. Zatem chcę użyć 256 Meg dimms. Nie mogę użyć chipsetu i815, bo dopuszcza maksymalnie 512 Meg. Płyta apollo pro jest jedną z niewielu, która ma cztery sloty dla dimm dopuszczające 1 Gig pamięci. Płyty athlona mają tylko trzy sloty, więc dopuszczają maksymalnie 768 Meg.

Jestem ostrożny jeśli chodzi o użycie DDR dram. Chipsety te nie są ,,w obiegu'' dostatecznie długo. Dodatkowo ram jest za drogi. Także A7M266 używa VIA 686b southbridge, co jak podejrzewam było źródłem problemów. Jakkolwiek te płyty mają 2 sloty DDR dimm i największa sprzedawana kość DDR ma 256 Meg. Zatem byłbym ograniczony do 512 Meg.

Być może powinienem się przemóc i użyć 512 Meg dimms. Niestety ich dostępność jest ograniczona przez cenę, nie jestem też pewny, czy wszystkie płyty je wspierają. Jakie płyty główne/chipsety są polecane dla maszyn o 1Gig lub więcej ramu.

• Czy to po prostu oznacza, że muszą być one kompilowane oddzielnie od jądra i ładowane przez insmod?
• Czy mogę "#włączać" ("#include" ;-]) pliki nagłówkowe jądra w moim module?
• Jeśli tak, to które?
• Co gdy te pliki nagłówkowe mają funkcje inline? (Czy to ma znaczenie?)

Jeżeli nie uda mi się dostać odpowiedzi bezpośrednio od Linusa, to czy ktoś mógłby podać mi dokument, plik albo wątek na liście dyskusyjnej, gdzie zostało to wytłumaczone?

Jeśli masz zamiar wypuścić tylko wersję binarną to sytuacja zależy od tego jak Twoi prawnicy zinterpretują pojęcie 'linkowania'. Komentarze Linusa na ten temat nie mają na nią wpływu, ponieważ nie ma on praw autorskich do całości jądra.

To samo odnosi się do kodu, znajdującego się pod 'specjalnymi ograniczeniami', jak w GPL nazywa się elementy, które zabraniają rzeczy, które są dozwolone w GPL.

Jeśli wypuszczasz moduły z kodem na warunkach, które są conajmniej tak "wolne" jak GPL (na przykład BSD bez klauzuli o reklamie) to nikt nie będzie się czepiał. Prawdopodobnie nie włączymy go do podstawowego jądra ze względu na brak ochrony przed pułapką patentową w licencji BSD, ale i tak nie podejrzewam abyś tego chciał.

Wydaje się, że w 2.4.4 funkcja "skb_cow" nagle przestała zwracać zmodyfikowane skb, natomiast zwraca wartość całkowitą oznaczającą sukces/niepowodzenie.

Oznacza to, że dla modułów sieciowych wymagających tej funkcji, nie ma kompatybilności kodu między 2.4.3 i 2.4.4.

"jeśli to możliwe", nie dawaliśmy gwarancji na całkowitą zgodność na poziomie kodu źródłowego. Co więcej, nadchodzi więcej takich zmian, na przykład błędy w quocie nie mogą być naprawione bez złamania kompatybilności na poziomie kodu dla systemów plików.

Możesz myśleć i argumentować odwrotnie, ale możliwość złamania zgodności kodu na poziomie źródeł jest jedną z naszych silnych stron (patrz: błąd w rsh w solaris z zeszłego roku, gdzie root był właścicielem gniazda może być jednym z przykładów dlaczego tak jest).

User-mode Linux można już używać na PPC Linux - może zostać "zbootowany" z dyskietki root z Debiana z init=/bin/sh i "rozejrzeć się". Działa, ale jest wciąż parę problemów.

Najnowszy patch jest dostępny z http://www.tartarus.org/~chris/user-mode-linux/, do nałożenia na wersję z CVS (patrz: http://user-mode-linux.sourceforge.net).

Po pierwsze chciałbym podziękować Chrisowi za chęć podjęcia trudu pierwszego przeniesienia UML na inną architekturę, zwłaszcza, że to naprawdę działa. To miłe zobaczyć, że UML nie jest przeznaczony jedynie na i386.

Bazując na tym czego nauczyłem się w trakcie tego przeniesienia, piszę właśnie rodzaj przewodnika jak przenosić UML. Będzie można go zobaczyć pod adresemhttp://user-mode-linux.sourceforge.net/arch-port.html jak tylko będzie cokolwiek gotowe. Na początku będzie on niekompletny - będę go uzupełniał w trakcie przedzierania się przez istniejący kod i wtedy gdy skoñczę integrować kod Chrisa z moim.

Zatem, jeśli tylko ktoś chce przenieść UML na inną architekturę, proszę spojrzeć na podaną stronę (i zaglądać na nią czasem, bo będę ją wypełniał :-). Zobaczycie, że nie trzeba włożyć w to wiele pracy. UML jest łatwy do przeniesienia.

W załączniku znajduje się sterownik dla karty NCR Dual 700 Microchannel. Odkąd w tej karcie pojawił się chip 53c700-66, który znajduje się także w wielu innych kartach SCSI, wyabstrachowałem funkcję ,,chipową'' (prawie w ten sam sposób w jaki funkcja dla chipa 8390 jest wyabstrachowana dla kart sieciowych) tak że będzie łatwo podłączyć ją do kodu dla każdej innej karty SCSI używającej 53c700-66. Jak to możecie zobaczyć, kod specyficzny dla samej karty to tylko około 150 linii.

Sterownik ma pełny zakres funkcji.

Wiem, że mamy dwa sterowniki, które podobno dają sobie radę z tymi chipami (53c7xx i 53c7,8xx), ale gdy skompiluje się je dla tych chipów nie działają. Chipy te są same w sobie prymitywne (nie mają table indirect mode, które jest podstawą późniejszych sterowników) i to powoduje, że pisanie osobnych sterowników ma sens.

Sterownik jest obecnie ,,I/O mapped'' (bo nie znam kart używających tego chipa, które nie byłyby I/O mapped), ale można je łatwo przerobić na ,,memory mapped'', dajcie mi tylko znać, że jest potrzeba.

Jak wygląda układ Win2k dynamic disk, to znaczy jaka jest struktura bazy danych Logical Disk Manager (LDM). Artykuł "Inside Storage Managment, Part 2" Marka Russinovich w magazynie Windows 2000 (pełny tekst dostępny za darmo pod adresem: http://www.win2000mag.com/Articles/Index.cfm?ArticleID=8303) opisuje w detalach logiczny układ bazy danych LDM, ale nie podaje wystarczającej liczby potrzebnych szczegółów, aby można było łatwo zaimplementować to pod Linuksem.

Linuks musi obsłużyć bazę danych LDM aby dać wsparcie dla podwójnego bootowania konfiguracji Win2k (albo XP) oraz Linuksa gdy jest jeden lub więcej dynamic disks w systemie a użytkownik chce mieć dostęp spod Linuksa do partycji NTFS rezydującej na dynamic disk.

Powiedzenie po prostu "Nie używaj dynamic disks jeśli chcesz używać Linuksa" jest IMHO bardzo złą rzeczą (a Bad Thingp(TM)) ponieważ użytkownik może kupić komputer z preinstalowanym Win2k na dynamic disk, albo nawet gorzej, może używać Win2k, a potem chcieć zainstalować na tym Linuksa. W tych przypadkach użytkownik będzie musiał reformatować cały system, chyba że Linux będzie jednak wspierać dynamic disks...