Kernel Traffic #150 For 14 Jan 2002

Nie są.

Żadna rozsądna osoba nie powinna używać framebuffera, jeśli ma wybór.

Tak, jak mówiła Ci mama: ,,Powiedz nie''. Używaj trybu tekstowego i X11, i będziesz szczęśliwy.

Oczywiście, niektórzy ludzie nie mają wyboru.

To w związku ze zmianą, której musiałem dokonać w jądrze 2.2.17-14, aby wspierało naprawdę duże dyski. W naszym projekcie mamy do czynienia ze sporymi dyskami, czasami większymi niż 128 GB. System plików to FAT32 i na każdym dysku tworzona jest tylko jedna partycja. Podczas testów zdaliśmy sobie sprawę, że implementacja fat-u w Linuksie nie obsługuje partycji większych niż 128 GB (w zasadzie 64 GB, z powodu błędu w implementacji fat).

To ograniczenie wynika ze struktury danych, używanej przez implementację fat-u w Linuksie do odczytu/zapisu zawartości katalogów. Przy dostępie do zawartości katalogów na dysku używany jest typ danych 'long', w którym zaledwie 28 bitów identyfikuje sektor z danymi, pozostałe 4 bity wskazują przesunięcie danych wewnątrz sektora. Używanie 28 bitów oznacza, że nie mamy dostępu do danych powyżej 128 GB (2^28*512), i tak ogranicza tworzenie partycji większych niż 128 GB na dużych dyskach.

Zmieniłem implementacje fat, vfat i msdos w jądrze tak, aby obsługiwały większe typy danych, w ten sposób pozwalając na tworzenie większych partycji. Co do GPL, chciałbym udostępnić łatkę wszystkim, także na wypadek, gdyby ktoś natknął się na podobny kłopot (kto przejmuje się fat-em w świecie linuksowym). Łatka została solidnie przetestowana tylko na naszych systemach (p3, 700MHz z FC). Naprawdę doceniłbym, gdybyście wy & gdyby ktokolwiek z lkml miał coś do powiedzenia o tych zmianach.

Łatka dotyczy tylko jądra 2.2.17-14 i może wymagać zmian, aby działała z innymi wersjami. O ile mi wiadomo, nie poprawiono tego w żadnej wersji jądra.

To problem Microsoftu -- to podstawowe ograniczenie formatu, który zdefiniowali. Samo to, że go w ogóle zdefiniowali, jest problemem (jedynym sposobem na zmuszenie systemu FAT do *dobrej* pracy jest załadowanie całego FAT-u do pamięci przed czasem, a FAT32 to psuje), zamiast stworzenia bardziej sensownego zastępstwa.

(FWIW, powód, którego użyli dla usprawiedliwienia FAT32 brzmiał ,,zmuszenie DOS-u do używania NTFS-u wymagałoby zbyt wiele wysiłku'', jakby to były jedyne możliwe wybory...)

teraz, gdy już wszystkie noworoczne zabawy się skoñczyły, wracamy do nudnych rzeczy. Dla tych, którzy chcą zobaczyć, a może nawet spróbować czegoś bardziej skomplikowanego, udostępniam tę łatkę, która prawie całkowicie przepisuje algorytm szeregowania procesów Linuksa dla 2.5.2-pre6:

http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.5.2-A0.patch

dla 2.4.17:

http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-A0.patch

Cel

Głównym celem nowego algorytmu jest zachowanie wszystkich tych dobrych rzeczy, które znamy i kochamy w aktualnym schedulerze Linuksa:

• niezłe interaktywne działanie nawet pod dużym obciążeniem: jeśli użytkownik pisze lub klika, system musi reagować natychmiast i płynnie wykonać zadania użytkownika, nawet ze sporym obciążeniem w tle.
• niezłe działanie szeregowania procesów/budzenia z 1-2 aktywnymi procesami.
• sprawiedliwy podział: żaden proces nie powinien pozostać bez swojego kawałka czasu na jakikolwiek nierozsądny okres czasu. Żaden proces nie powinien dostać niesprawiedliwie dużej ilości czasu CPU.
• priorytety: banalniejsze zadania mogą rozpocząć się z niższym priorytetem, ważniejsze z wyższym priorytetem.
• wydajność SMP: żaden procesor nie powinien pozostawać bezczynny, jeśli jest praca do wykonania.
• powinowactwo SMP: procesy działające na jednym procesorze powinny pozostać z nim spokrewnione. Procesy nie powinny skakać między procesorami zbyt często.
• oraz dodatkowe cechy algorytmu szeregowania procesów: szeregowanie RT, przywiązanie do CPU .

celem jest także dodanie kilku nowych rzeczy:

• pełne szeregowanie O(1). Czy jesteś zmęczony pętlą przeliczającą co rusz wywalającą cały cache L1? Czy uważasz, że dobrotliwa pętla (goodness loop) trwa troszkę zbyt długo, jeśli działają jakieś procesy? Nowy algorytm nie bierze jeñców: wakeup(), schedule(), przerwania zegara są wszystkie algorytmami O(1). Nie ma pętli przeliczającej. Nie ma również dobrotliwej pętli.
• ,,doskonała'' skalowalność SMP. Przy nowym algorytmie szeregującym nie ma ,,dużej'' blokady runqueue_lock -- istnieją kolejki zadañ do wykonania i ich blokady dla każdego procesora -- dwa zadania na dwóch różnych procesorach mogą się zbudzić, uszeregować i przełączyć kontekst zupełnie równolegle bez żadnego podblokowywania się. Wszystkie struktury danych związane ze schedulerem są zoptymalizowane pod kątem skalowalności (popatrzcie też parę akapitów niżej na wyniki testów.)

• lepsze powinowactwo SMP. Stary scheduler miał tę słabość, że powodował losowe przemieszczanie się zadañ pomiędzy procesorami, jeśli/gdy pojawiały się zadania z wyższym priorytetem/interaktywne, co było zaobserwowane i zgłoszone przez wiele osób, Przyczyną jest fakt, że pętla obliczająca kwant czasu wymaga, aby każde aktywne zadanie wykorzystało przydzielony mu wcześniej kwant czasu. Ale gdy dzieje się to na np. maszynie 8-procesorowej, to ta własność nie pozwala uruchomić tego zadania na żadnym z pozostałych procesorów. Gdy, w koñcu, ostatnie zadanie wykorzysta przydzielony mu kwant czasu, budzona jest pętla licząca i dopiero wtedy inne procesory mogą zacząć wykonywać nowe zadania -- po tym jak się bezczynnie obijały. Im więcej procesorów, tym gorszy wynik.

  Ponadto, ten sam efekt powoduje także efekt odbijania: kiedy tylko pojawia się ,,ściśnięty kwant czasu'' w globalnej kolejce zadañ, bierne procesory zaczynają wykonywać zadania, które nie są spokrewnione z tym procesorem. (ponieważ spokrewnionym procesom skoñczyły się ich kwanty czasu)

  Nowy scheduler rozwiązuje problem dzielenia kwantów czasu dla poszczególnych procesorów bez globalnej synchronizacji i bez globalnych przeliczeñ.

• szeregowanie wsadowe. Znaczna część zadañ wymagających wielu obliczeñ zyskuje przy zastosowaniu szeregowania wsadowego, gdzie kwanty czasu są długie, a procesy są szeregowane algorytmem round-robin. Nowy scheduler stosuje takie wsadowe szeregowanie dla zadañ z najniższym priorytetem -- zatem zadania z nice +19 będą automatycznie ,,zaszeregowane wsadowo''. Przy tym schedulerze, z interaktywnego punktu widzenia, zadania z nice +19 są w gruncie rzeczy SCHED_IDLE.
• łagodniej traktuje ekstremalne obciążenia, bez załamañ i burz przy szeregowaniu.
• szeregowanie RT w czasie O(1). Dla ludzi związanych z RT, którzy mają fioła na punkcie złożoności O(nr_running) w dobrotliwej pętli oraz w pętli przeliczającej.
• wykonywanie zfork()owanych potomków przed rodzicem. Andrea wskazał korzyści takiego podejścia już kilka miesięcy temu, ale łaty nie koegzystowały zbyt dobrze ze starym schedulerem, ponieważ leniuchujący procesor często podkradał nowe dziecko zanim fork()ujący procesor zaczął go wykonywać.

Projekt

(jeśli kogoś znudzi poniższy opis, może od razu przejść do sekcji 'Testy'.)

rdzeñ nowego algorytmu szeregującego stanowią następujące mechanizmy:

• *dwie*, uszeregowane względem priorytetu ,,tablice'' na procesor. Jest tablica ,,aktywna'' i tablica ,,wygasła''. Tablica aktywna zawiera wszystkie zadania, które są spowinowacone z tym procesorem i jeszcze został im jakiś kwant czasu. Tablica wygasła zawiera wszystkie zadania, które już zużyły swoje kwanty czasu, ale ta tablica również jest posortowana. Do żadnej z tych tablic nie odwołujemy się bezpośrednio, ale przez dwa wskaźniki w strukturze runqueue dla każdego CPU. Gdy wszystkie zadania już wykorzystają swój czas, wówczas ,,zamieniamy'' te dwa wskaźniki i teraz tablica wygasła staje się tablicą aktywną, a pusta tablica aktywna zaczyna służyć jako zbiór zadañ, które zużyły swój kwant czasu.
• jest też 64-bitowa mapa w pamięci podręcznej na indeksy tych tablic. Znalezienie zadania z najwyższym priorytetem wymaga dwóch instrukcji przeszukania bitów x86 BSFL.

rozwiązanie z dwoma tablicami pozwala nam na posiadanie dowolnej liczby aktywnych i wygasłych zadañ, a ponowne przeliczenie kwantów czasu może być wykonane, gdy tylko przydzielony kwant czasu się skoñczy. Ponieważ tablice są zawsze dostępne za pośrednictwem wskaźników w kolejce zadañ do wykonania, zamienianie tablic może być wykonane bardzo szybko.

to jest hybrydowe podejście list piorytetowych połączone z szeregowaniem round-robin i metodą zamieniania tablic z rozproszonych kwantów czasu.

• dla każdego zadania istnieje ,,estymator obciążenia''.

jedną z trudniejszych rzeczy jest zagwarantowanie dobrej interaktywności przy dużym obiążeniu. Podczas zabaw z różnymi wersjami schedulera okazało się, że najlepsze odczucie interaktywności występuje, nie gdy ,,dożywiamy'' interaktywne zadania, ale gdy ,,karzemy'' zadania, które chcą zużyć więcej czasu procesora niż jest dostępne. Ta metoda jest również łatwiejsza do zaimplementowania w stylu O(1).

aby ustalić rzeczywiste ,,obciążenie'', jake zadanie generuje, użyta jest wyglądająca na skomplikowaną, ale dość dokładna metoda: jest 4-pozycyjny pierścieñ ,,historii'', zawierający informacje o aktywności zadañ w ciągu ostatnich 4 sekund. Na tym pierścieniu można operować bez zbyt wielkiego narzutu. Kolejne pozycje dają schedulerowi dość dokładną historę obciążenia generowanego przez zadanie: czy zużyło więcej czy mniej czasu procesora w ciągu ostatnich N sekund. [rozmiar ,,4'' i przedziały 4x 1 sekunda zostały wyznaczone ekperymentalnie - ta część jest elastyczna i może zostać zmieniona w obu kierunkach.]

zadanie jest karane za wygenerowanie większego obciążenia, niż procesor jest w stanie obsłużyć. Karą tą jest obniżenie priorytetu -- istnieje maksymalna wysokość kary w stosunku do statycznego priorytetu, więc nawet zadania, które się ,,przyklejają'' do procesora będą wzajemnie obserwować swoje priorytety i odpowiednio dzielić CPU.

Oddzieliłem szeregowanie RT do innej podstawy kodu, zachowując jednocześnie część podstawowego kodu jako wspólną. To nie wygląda zbyt ładnie, zwłaszcza w takich miejscach, jak __sched_tail() czy activate_task(), ale nie sądzę, aby można było temu zapobiec. Szeregowanie RT jest inne, wykorzystuje globalną kolejkę zadañ (i globalną blokadę) i potrzebuje globalnych decyzji. Aby przyspieszyć szeregowanie RT i upewnić się, że zadania RT z odpowiednim priorytetem są odpowiednio uszeregowane, dodałem wiadomość rozgłoszeniową z przeszeregowaniem, nawet na systemach SMP. Szeregowanie RT ma również złożoność O(1).

load-balancer SMP może być rozszerzony/zmieniony przy pomocy dodatkowych równoległych obliczeñ i koncepcji hierarchicznej pamięci podręcznej: szeregowanie NUMA, wielordzeniowe CPU mogą być w prosty sposób obsłużone przez zmianę load-balancera. W tej chwili jest on dopasowany do moich systemów SMP.

pominąłem zaletę prev->mm == next->mm - żadne obciążenie jakie znam nie wykazuje jakiejkolwiek reakcji na to. Można to z powrotem włączyć poprzez poświęcenie schedule() działającego w czasie O(1) [listy priorytetów, obecna i przesunięta o jeden w dół, mogą być przeszukane na okoliczność warunku that->mm == current->mm], ale to kosztuje nas sporą liczbę cykli przy pewnej liczbie ważnych obciążeñ, dlatego chciałem omijać to jak tylko się da.

• kod startowy biernych procesów SMP wciąż był podatny na wyścigi, a nowy algorytm szeregowania danych je wywoływał. Zatem nieco ujednoliciłem kod idle-setup. Nie odwołujemy się do schedule(), dopóki nie włączą się w pełni wszystkie procesory i wszystkie bierne procesy nie znajdą się na swoich miejscach.
• łata porządkuje także parę rzeczy w sched.c -- tam, gdzie do słuszne, przesuwa kod do innych części jądra i upraszcza część ścieżek w kodzie i struktur danych. W wyniku, nowy scheduler jest mniejszy niż jego poprzednik.

(z pewnością są też inne szczegóły, których zapomniałem wyjaśnić. Skomentowałem część ważniejszych kawałków kodu i struktur danych. Jeśli sądzisz, że któryś aspekt projektu jest błędny, lub brakuje w nim czegoś istotnego, proszę, powiadom mnie o tym.)

(obecny kod w żadnym razie nie jest doskonały, w tej chwili moim głównym celem, poza poprawieniem błędów, jest zrobienie kodu bardziej przejrzystym. Wszelkie sugestie uproszczeñ są mile widziane.)

Testy

wykonałem dwa rodzaje testów: najpierw sprawdzałem wrażenie interaktywnści przy nowym schedulerze na systemach UP i SMP. Chociaż jest to dość subiektywne odczucie, to uważam, że nowy scheduler sprawuje się nie gorzej niż stary, a przy niektórych wysokich obciążeniach, jest nawet lepiej. Sprawdzałem wiele obciążeñ m. in. wykonując kompilację make -j w tle, uruchamiając 1000 procesów, i stwierdziłem, że oba schedulery nie mają problemów z zapomnianymi procesami, czy dużymi opóźnieniami w przypadku SMP.

inna grupa testów miała za zadanie zbadać rzeczywistą wydajność schedulera. Spośród nich wybrałem następujące (niektóre miały jedynie obciążyć scheduler, inne miały dać szerszy obraz jego zachowañ):

• testy kompilacji
• symulator obciążenia serwera chat, napisany przez Billa Hartnera
• zwykłe składniki z zestawu lmbench
• bardzo sched_yield()-ujący program testowy do pomiaru wydajności yield().

[mogę też przetestować inne obciążenia, które wydadzą się komuś interesujące.]

przeprowadziłem te testy na komputerze jednoprocesorowym z jądrem UP oraz na komputerach dwu- i ośmioprocesorowych z jądrem SMP.

Symulator serwera chat tworzy pewną liczbe procesów połączonych ze sobą przez gniazda TCP, procesy losowo wysyłają do siebie wiadomości, w ten sposób, że symulują właściwie strukturę i obciążenie sewerów chat.

3 kolejne przebiegi './chat_c 127.0.0.1 10 1000' zaowocowały w następującej przepustowości wiadomości:

vanilla-2.5.2-pre6:

Średnia przepustowość : 110619 wiadomości na sekundę
Średnia przepustowość : 107813 wiadomości na sekundę
Średnia przepustowość : 120558 wiadomości na sekundę

O(1)-schedule-2.5.2-pre6:

Średnia przepustowość : 131250 wiadomości na sekundę
Średnia przepustowość : 116333 wiadomości na sekundę
Średnia przepustowość : 179686 wiadomości na sekundę

to jest prawie 20% poprawa.

Aby wykorzystać wszystkie zalety nowego schedulera, uruchomiłem to ze zmienionym priorytetem, co, w gruncie rzeczy, uruchomiło zadania serwera chat uszeregowane przy wykorzystaniu wsadowego szeregowania round-robin:

3 kolejne przebiegi 'nice -n 19 ./chat_c 127.0.0.1 10 1000' zaowocowały następującą przepustowością:

vanilla-2.5.2-pre6:

Średnia przepustowość : 77719 wiadomości na sekundę
Średnia przepustowość : 83460 wiadomości na sekundę
Średnia przepustowość : 90029 wiadomości na sekundę

O(1)-schedule-2.5.2-pre6:

Średnia przepustowość : 609942 wiadomości na sekundę
Średnia przepustowość : 610221 wiadomości na sekundę
Średnia przepustowość : 609570 wiadomości na sekundę

przepustowość wzrosła ponad 600%. Wyniki testów na UP i dwuprocesorowym SMP pokazują mniej więcej taką samą przewagę nowego algorytmu szeregującego. Co więcej, przy testach z serwerem chat, stary scheduler nie obsługiwał zbyt dobrze zadañ interaktywnych i system był bardzo spowolniony. (co jest skutkiem ubocznym sytuacji przeszeregowania, w którą wpada scheduler.)

na jednoprocesorowym UP wyniki też są interesujące:

vanilla-2.5.2-pre6:

./chat_c 127.0.0.1 10 100
Średnia przepustowość : 102885 wiadomości na sekundę
Średnia przepustowość : 95319 wiadomości na sekundę
Średnia przepustowość : 99076 wiadomości na sekundę

nice -n 19 ./chat_c 127.0.0.1 10 1000
Średnia przepustowość : 161205 wiadomości na sekundę
Średnia przepustowość : 151785 wiadomości na sekundę
Średnia przepustowość : 152951 wiadomości na sekundę

O(1)-schedule-2.5.2-pre6:

./chat_c 127.0.0.1 10 100 # NEW
Średnia przepustowość : 128865 wiadomości na sekundę
Średnia przepustowość : 115240 wiadomości na sekundę
Średnia przepustowość : 99034 wiadomości na sekundę

nice -n 19 ./chat_c 127.0.0.1 10 1000 # NEW
Średnia przepustowość : 163112 wiadomości na sekundę
Średnia przepustowość : 163012 wiadomości na sekundę
Średnia przepustowość : 163652 wiadomości na sekundę

to pokazuje, że chociaż na UP nie widać poprawy skalowalności, szeregowanie O(1) i tak jest lepsze.

kolejny test mierzy wydajność sched_yield(). (od której, w dużej mierze, zależy kod pthreads.)

na dwuprocesorowym systemie, po wystartowaniu 4 kopii ./loop_yield, otrzymałem następującą wydajność względem przełączeñ kontekstu:

vanilla-2.5.2-pre6

  # vmstat 5 | cut -c57-
     system         cpu
   in    cs  us  sy  id
  102 241247   6  94   0
  101 240977   5  95   0
  101 241051   6  94   0
  101 241176   7  93   0

O(1)-schedule-2.5.2-pre6

  # vmstat 5 | cut -c57-
     system         cpu
   in     cs  us  sy  id
  101 977530  31  69   0
  101 977478  28  72   0
  101 977538  27  73   0

scheduler O(1) jest o 300% szybszy i wykonujemy prawie 1 milion przełączeñ kontekstu na sekundę!

ten test wygląda jeszcze lepiej na ośmioprocesorowym systemie, na którym działa 16 kopii loop_yield:

vanilla-2.5.2-pre6:

   vmstat 5 | cut -c57-
      system         cpu
    in     cs  us  sy  id
   106 108498   2  98   0
   101 108333   1  99   0
   102 108437   1  99   0

100K przełączeñ kontekstu na sekundę -- narzut w globalnej kolejce spowalnia scheduler w porównaniu do maszyny dwuprocesorowej!

O(1)-schedule-2.5.2-pre6:

    vmstat 5 | cut -c57-
     system         cpu
    in      cs  us  sy  id
   102 6120358  34  66   0
   101 6117063  33  67   0
   101 6117124  34  66   0

to jest ponad 6 milionów przełączeñ kontekstu na sekundę! (sądzę, że to jest najlepszy wynik w historii, żadna inna maszynka działająca pod Linuksem nigdy wcześniej nie osiągnęła takiej liczby przełączeñ kontekstu na sekundę). To jest nalepszy przykład, w którym kolejki zadañ per CPU i zalety skalowalności pokazują pazurki.

a oto porówniania lat_proc i lat_ctx (wyniki tu wklejone to najlepsze wyniki z serii testów):

vanilla-2.5.2-pre6:

./lat_proc fork
Przetwarzanie fork+exit: 440.0000 mikrosekund
./lat_proc exec
Przetwarzanie fork+execve: 491.6364 mikrosekund
./lat_proc shell
Przetwarzanie fork+/bin/sh -c: 3545.0000 mikrosekund

O(1)-schedule-2.5.2-pre6:

./lat_proc fork
Przetwarzanie fork+exit: 168.6667 mikrosekund
./lat_proc exec
Przetwarzanie fork+execve: 279.6500 mikrosekund
./lat_proc shell
Przetwarzanie fork+/bin/sh -c: 2874.0000 mikrosekund

różnica jest olbrzymia -- głównie dzięki uniknięciu większości narzutu COW, który wynika z wykonania fork()+execve(). Poprawa fork()+exit() wynika głównie z lepszego powinowactwa CPU -- rodzic i potomek działają na tym samym procesorze, podczas gdy stary scheduler wysyłał potomka na inny, nieużywany procesor, co powodowało duży, blokujący ruch pomiędzy strukturami MM.

testy kompilacji dały bardzo podobne wyniki przy obu schedulerach. Algorytm szeregujący O(1) dał małą, 2% przewagę przy testach wykorzystujących make -j (to się mieści w granicach błędu statystycznego -- ciężko jest przeprowadzić solidne testy kompilacji) -- przypuszczalnie ponownie z powodu lepszego powinowactwa CPU.

Stan

przetestowałem nowy scheduler w dużym zakresie systemów i obciążeñ, ale jest to jeszcze kod eksperymentalny. Rozwijałem go używając jąder 2.5.2-pre na systemach SMP, więc w tym zakresie jest najlepiej przetestowany, ale wykonałem też dość dużo testów na UP i 2.4.17. UWAGA! Przy jądrze 2.5.2-pre6 musicie najpierw zaaplikować ostatnią łatę Andriesa, 2.5.2pre6-kdev_t dostępną pod adresem:

http://www.kernel.org/pub/linux/kernel/people/aeb/

przetestowałem także szeregowanie RT w różnych sytuacjach, takich jak sched_yield()-owanie zadañ RT, strace-owanie zadañ RT i różnych innych, i to działa tak, jak oczekiwałem. Może być jednak parę chropowatości.

Nie bierz tego za złe, nie chcę na Ciebie ani na nikogo bluzgać, ale sądzę, że jeśli każdy publicznie ogłosi swoje drzewo Linuksa, z własnym zbiorem łat na główne jądro, to w ten sposób zniechęci wielu użytkowników.

Mamy ,,tylko'' trzy główne drzewa w stabilnych wersjach :

• Oficjalne jądra Linusa
• Alana, który wykonał świetną robotę łącząc stabilny rdzeñ z eksperymentalnymi sterownikami
• Jądro Andrei, które jest orientowane na wielkie serwery i bardzo wysokie obciążenia.

Teraz, gdy Alan pracuje nad czymś innym, łatwo mi zrozumieć, że ludzie potrzebują gałęzi takiej jak ta utrzymywana przez niego, nawet w sytuacji, w której większość jego pracy została włączona do głównego drzewa.

Ale teraz jest drzewo -mjc, drzewo -nj, pewnie inne, których nie zauważyłem i wiele innych nie ogłaszanych tu (-wt, pamietam -ma Mathiasa Andree na przykład, który był chyba pierwszym, który włączył ext3 i reiserfs w to samo jądro). Wszystkie one zawierają prawie te same zbiory poprawek, które jeszcze nie znalazły się w oficjalnym jądrze, oraz zbiór mniej lub bardziej stabilnych, mniej lub bardziej interesujących cech (w zależności od celu produkowanych zbiorów łat). Każdy powinien, conajmniej, ogłosić cel, w którym tworzy swoje jądro i komu ono ma służyć: deweloperom, użytkownikom na maszyny produkcyjne, użytkownikom desktopów, testerom, wszystkim? Po treści Twojego ogłoszenia nie widać, jakie ryzyko podejmuje się używając Twojego jądra. Na przykład: sądzę, że co najmniej Andre Pavenis ciągle ma problemy ze sterownikiem i810_audio Douga, więc ten sterownik nie może być ogłaszany po prostu jako ,,poprawka'' bez żadnego komentarza.

Oczywiście wiem, że opieka na zbiorem łat na główne jądro zabiera mnóstwo czasu, a jeszcze więcej czasu zabiera czytanie raportów o błędach i określanie, co jest stabilne, a co nie jest. Nie trzeba nawet mówić o tuzinach kompilacji przed ogłoszeniem (bo je kompilujecie, nieprawdaż?), i od czasu do czasu przenoszenie pewnych poprawek na inne architektury.

Zatem naprawdę myślę, że byłoby bardziej produktywne, gdyby ludzie pracowali nad mniejszą liczbą drzew, przestali ciągle edytować ręcznie łaty aby rozwiązać niektóre konflikty i probować by były bardziej zrozumiałe dla nowicjuszy, którzy są trochę zgubieni, gdy nie wiedzą, które jądro wypróbowywać.

Być może powinieneś był wysłać swoje łaty Mickaelowi Cohenowi, by pomóc mu szybciej wypuścić -mjc2, tak jak to wszyscy robiliśmy z Alanem? Albo może powinieneś ułożyć sobie w głowie jasny plan, jak powinno wyglądać Twoje jądro, ale w tym wypadku opisz to trochę dokładniej, niż jedną wiadomością i przygotuj się na raporty o błędach przychodzące od ludzi, którzy uwierzą w Twoją wersję jądra. Ta ostatnia rzecz jest chyba najważniejszą przyczyną, dla której zdecydowałem się oferować moje jądra tylko moim przyjaciołom i mnie samemu...

Mam nadzieję, że nie przyjąłeś tego jako ataku, tak naprawdę, to nie było skierowane przeciwko tobie, nie było też wywoływaniem wojny na bluzgi, napisałem to, by skłonić ludzi do myślenia o czymś bardziej konstruktywnym.

Jestem autorem 'Linux kernel source finder' - strony www, na której wymieniono miejsca, w których można uzyskać łaty na jądro Linuksa dla każdej architektury - zobaczcie:

http://www.treblig.org/Linux_kernel_source_finder.html

Chciałbym ją poszerzyć tak, by zawierała odnośniki do najlepszych/najnowszych/najbardziej odpowiednich binutilsów dla każdej architektury. Umieściłem odnośniki do nich dla x86, Alphy i MIPS prowadzące do ftpa H.J.Lu, bo dla tych trzech platform prowadzi on testy przed wypuszczeniem.

Będę wdzięczny za rekomendacje i komentarze od tych, którzy używają binutils na Linuksie na innych platformach, będę też wdzięczny za odnośniki do ftpów, repozytoriów cvs i stron www, opisujących rozwiązania stosowane dla tych architektur.