Kernel Traffic #181 For 2002/08/26

Wybaczcie, ale jest tu tona różnych rzeczy. Skończyło się na diffie o 4600 liniach. To prawie cała praca nad wydajnością, która była w bólach testowana na dużych maszynach; główny problem polegał na tym, żeby w ogóle wystartować na tym 2.5. Wyniki ciągle nie pozwalają wyciągnąć takich wniosków, jakie chciałem uzyskać, ale wygląda to dobrze i nie ma innych propozycji, które naprawiają ten problem.

Większość tych zmian już proponowałem.

• Zmieniłem sector_t w max_block, aby używało podejścia przedstawionego przez davem. Zgadzam się z Antonem, ale robienie tego bezpośrednio nie boli.
• Usunąłem nieistotny komentarz w copy_strings.

Stare rzeczy:

• Usunięcie ostrzeżenia o błędzie WE/WY w end_buffer_io_sync(). Wyzwalają je nieudane próby READA.

• Wypisz ostrzeżenie, gdy ext2 montuje system plików ext3.

  Mieliśmy kilka zgłoszeń błędów z tym związanych, głównie wynikających z problemów z initrd. A mount(8) zwykle zgłasza fstype z /etc/fstab, a nie opisuje, co się naprawdę zdarzyło.

Poprawienie niepotrzebnych rzeczy, które dodałem do max_block():

• `size' nie musi być typu sector_t
• `retval' nie powinno być inicjalizowane wartością ,,~0UL'', bo to jest 0x00000000ffffffff przy 64-bitowym sector_t.
• Alokacja task_structs z GFP_KERNEL, jak to było dyskutowane.
• Zamiana EXPORT_SYMBOL dla generic_file_direct_IO() na EXPORT_SYMBOL_GPL. To było eksportowane w zasadzie tylko do użytku surowego sterownika.

• Pętla wątków uruchamia balance_dirty_pages() po zabrudzeniu powracającego pliku. Zatem wykonywany będzie zapis pliku, gdy jest dużo zabrudzonej pamięci. W tym celu eksportuję balance_dirty_pages do modułów na GPL.

  To sprawia, że pętla działa dużo lepiej - podejrzewam, że się psuło, gdy rzeczy, które wołały balance_dirty_pages() zaczynały zapisywać z powrotem tylko własne kolejki.

  Przy dużym zapisie w pętli zdarza się wiele błędów alokacji. Pochodzą z alokacji blk_queue_bounce() z puli pamięci page_pool. Zatem...

• Wyłączyłem ostrzeżenia alokacji stron przy początkowej atomowej próbie alokacji w mempool_alloc() -- tej, gdzie __GFP_WAIT i __GFP_IO są wyłączone. To jedno może łatwo się zepsuć.
• Dodałem komentarze do block_write_full_page()

Zrobiłem kilka testów, ponieważ zawsze myślałem, że zachowanie zapisu w 2.4 (i 2.5) pozostawia trochę do życzenia. Testowanie odbyło się na SMP x86 (2xPPro-200) z 160MB RAM. Użyłem ulubionego przez wszystkich kozła ofiarnego: IDE, z pojedynczym, nie-za-szybkim dyskiem IBM. Systemem plików było ext3 w trybie data=ordered. Obciążeniem testowym był przychodzący (z punktu widzenia testowanego systemu) transfer FTP 600 MB obrazu iso. Wszystkie testy działają na czystym systemie z wyłączonymi niepotrzebnymi serwisami.

Wyniki (średnia z 4 uruchomień):

2.5.31-akpm: 2m 43s
2.5.31:      2m 33s
2.4.19:      2m 18s

`vmstat 1` pokazuje pewne różnice, w szególności w odniesieniu do 2.4 vs 2.5. W około 40% przypadków, gdy bo spada do (prawie) 0, maszyna przestaje działać (transfer FTP się zawiesza, wyjście vmstat się przerywa, itp.). Przy 2.5.31-akpm, przerwy trwały około 3-4 sekund. Przy 2.5.31 przerwy trwały tyle samo, ale zdarzały się troszeczkę rzadziej. Przy 2.4.19 przerwy były bardzo częste (mniej więcej 70% czasu, gdy bo zbliżało się do 0), ale trwały tylko 1-2 sekundy.

Poniżej zamieszczam reprezentatywne próbki `vmstat 1` dla każdego jądra, z czasu trwania testu. (Zauważcie, że niskie użycie cache w próbce z 2.5.31, jest spowodowane tym, że migawka pochodzi z początku uruchomienia, gdy cache się ciągle wypełniało.)

tak. Dla tego obciążenia (transfer ftp z prędkością 10 mbajtów/sek, gdzie dysk ma transfer >20 meg/sek), aplikacja nigdy nie powinna blokować WE/WY -- cały zapis powinien odbywać się przez pdflush.

2.4 zaczyna zapisywanie w tle przy 30% brudnych stron, a synchroniczny zapis przy 60%.

2.5 zaczyna zapisywanie w tle przy 40% brudnych stron, a synchroniczny zapis przy 50%.

Możesz zrobić tak, żeby 2.5 używało ustawień 2.4 przez:

cd /proc/sys/vm
echo 30 > dirty_background_ratio
echo 60 > dirty_async_ratio
echo 70 > dirty_sync_ratio

i spodziewam się, że przekonałeś się, iż daje to poprawę. Ustawienie dirty_background_ratio na 10% powinno jeszcze poprawić sytuację. Ale to pogorszy liczby w dbench przy pewnej liczbie klientów, co aż prosi się o stan wyjątkowy.

Hmpf. Nie wiem jakie są właściwe liczby. Nie ma żadnych; to jest właśnie problem z magicznymi liczbami. Ta część jądra wykonuje zapis i gardłowe decyzje, zupełnie nie przejmując się całościowym stanem systemu.

W najgorszym wypadku możemy ustawić to w 2.5 na takim samym poziomie jak w 2.4, ale wolałbym, gdyby ktoś zrobił to coś dynamicznie.

W rzeczywistości, skłaniałbym się do ustawienia tego współczynnika na niższym poziomie niż w 2.4 i olania dbench. Niższy poziom jest lepszy dla prawdziwych programów, tak jak to zaobserwowałeś.

Rany. Widziałem ołówki, które mogą pisać szybciej niż to.

Zatem prędkość twoich kabli przewyższa prędkość dysku. To wszystko zmienia.

Jądro *musi* zatrzymywać generator brudnych danych. Możemy te zatrzymania skrócić i zrobić częstszymi. Zajrzyj do drivers/block/ll_rw_blk.c i zobacz, gdzie jest inicjalizowane batch_requests. Zamień to po prostu na:

batch_requests = 1;

batch_requests musi jakoś się kończyć...

A w fs/mpage.c ustaw RATELIMIT_PAGES na 16.

Aplikacja musi się blokować, ale dysk nigdy nie powinien wchodzić w tryb jałowy. Pobawię się tym trochę. IDE przestało być opcją w 2.5.30, co nie pomaga tym wysiłkom.

*Prawidziwe* przełączenie się na ext2 (zamiast tylko udawania) dało ogromną różnicę. Nowe liczby:

2.5.31-stock: 1m 49s
2.5.31-akpm: 1m 50s
2.4.19-stock: 1m 34s

...ale, przy zastosowaniu progów zapisu, które zaproponowałeś:

2.5.31-stock: 1m 34s
2.5.31-akpm: 1m 34s

(To znaczy przy dirty_background na poziomie 30%; 10% dało te same liczby co 30%.)

Prawdopodobnie przy dysku jako wąskim gardle, od zmian -akpm nie oczekuje się zbyt wiele. Przynajmniej niczego nie pogarsza.

załączona łatka implementuje nowe wywołanie systemowe na x86, clone_startup(). Paremetry to:

clone_startup(fn, child_stack, flags, tls_desc, pid_addr)

przy pomocy tej funkcji systemowej pthreads nowej generacji w glibc mogą tworzyć wątki jednym wołaniem systemowym: clone_startup() ustawia TLS dziecka i zapisuje jego PID z powrotem do przestrzeni użytkownika. (którego adres wskazuje na blok kontrolny wątku.).

PID dziecka musi być z powrotem zapisany, bo w przeciwnym wypadku rodzic i dziecko musieliby wykonywać kosztowną i niepewną synchronizację. Pierwszą instrukcją wykonywaną przez dziecko może być też obsługa sygnału, a kod glibc potrzebuje TLS i PID wątku. Jest kilka możliwych obejść tego problemu w przestrzeni użytkownika bez clone_startup(), ale każde z nich ma wady:

• rodzic może wyłączyć wszystkie sygnały na czas wołań clone(). To wymaga dodania 3 dodatkowych wołań systemowych: dwóch w rodzicu i jednego w dziecku. Stary kod LinuxThreads robił coś takiego.
• glibc mogłaby sprawdzać, czy dostępny jest PID i wołać getpid() jeśli nie jest, ale to wprowadza narzut w trakcie wykonywania.
• glibc mogłaby definiować funkcję-wrapper dla funkcji obsługi sygnałów - to jest zarówno niezdrowe, jak i mogłoby powodować problemy z kompatybilnością.
• glibc mogłaby używać muteksa, żeby pozwolić rodzicowi wypełnić PID. To wymaga dwóch dodatkowych przełączeń kontekstu, jeśli dziecko jest wykonywane pierwsze po clone().

a skoro jądro potrafi naprawdę dostarczyć całkiem dobrego rozwiązania, to dlaczego nie zrobić tego w ten sposób.

zrobienie TLS pozwala unikąć dodatkowych wywołań systemowych set_thread_area(). [Samodzielne aplikacje korzystające z glibc stale używają set_thread_area(), więc to wołanie nie powoduje bezużyteczności set_thread_area().]

Kwestie implementacji: wprowadziłem nową wewnętrzną flagę do jądra, flagę do clone, CLONE_STARTUP. Teoretycznie moglibyśmy użyć istniejącego wołania clone() i pozwolić aplikacjom wypełniać CLONE_STARTUP - nie byłem pewien tego rozwiązania, bo wprowadza ono parametryzowanie sys_clone() zależne od wersji, co powoduje bałagan. Ale niewątpliwie działałoby to bezpiecznie i sensownie, a nawet trochę wolniej niż rozwiązanie z oddzielnymi wołaniami systemowymi dodawane przez tę łatkę.

z przyczyn wydajnościowych jądro nie rozpoznaje numeru deskryptora -1 TLS, ale to nie problem, wątki potomne i tak dziedziczą po rodzicu indeks TLS. Jądro nie umożliwia też definiowania ,,pustych'' TLS.

Zgadzam się, że nazwa jest trochę paskudna, ale jest to wołanie systemowe, które moim zdaniem jest użyteczne (to znaczy widzę, jak to mogłoby być użyteczne, zupełnie pomijając różne problemy z implementacją).

Obgadanie tego z ludźmi od wątków w IBM ciągle ma jednak sens. Być może goście z IBM mają problemy z _inną_ informacją i łatwo może się okazać, że inferfejs, którego naprawdę potrzebujemy jest jeszcze bardziej ogólny.

To na pewno nie jest problem specyficzny tylko dla pthread. Semantyka starego Uniksowego fork() przy zwracaniu <pid> jest istotnie zepsuta, jako że ustalenie zwracania pid w lokalnym rejestrze w naturalny sposób powoduje wyścig w _czymkolwiek_, co chce utrzymywać listę własnych dzieci i chce dostawać się do tej listy przez funkcję obsługi SIGCHLD.

(Proste wyjaśnienie: wyboraźcie sobie dziecko, które kończy się tak szybko, że rodzic nie ma nawet czasu, by wykonać ,,zapis pid do tablicy'', zanim jest powiadomiony przy pomocy SIGCHLD. Tak, to się zdarza i tak, to jest prawdziwy problem. Nie tak dawno temu bash się na tym _wywalał_).

Z wołaniem systemowym takim jak to, rodzic może:

• zaalokować najpierw blok informacji nowego dziecka.
• wykonać fork ze wskaźnikiem pid pokazującym na blok informacji dziecka.
• gdy przychodzi SIGCHLD dla tego dziecka, cały stan jest już przygotowany, nie ma wyścigów.

Zauważcie jak to nie jest nawet specyficzne dla wątków: działałoby to z normalnym podejściem fork i standardową powłoką.

spawn() według mnie implikuje wykonanie równoważności ,,vfork()+execve()'', w sposób, w który większość systemów nie-uniksowych wykonuje tworzenie procesu.

Nie jest tak, że jakoś wyjątkowo nie lubię nazwy ,,wątek'', ale chciałbym żeby to było możliwie ogólne i tak postrzegane. W ten sam sposób, w jaki oryginalne clone() było właściwym nadzbiorem fork(), to to musi być właściwym nadzbiorem, nie tylko z nazwy, ale z _użycia_. Jeśli jest to użyteczne tylko w jedynym przypadku, to nie jest dobre.

w porządku, załączona łata pozbywa się clone_startup(), a w zamian dodaje dwie nowe flagi do clone():

CLONE_SETTLS => jeśli ustawione, to trzeci parametr wołania clone() jest nowym TLS.

CLONE_SETTID => jeśli ustawione, to TID dziecka jest zapisywany pod adres podany przez czwarty parametr clone().

nowe parametry są obsługiwane w bezpieczny sposób, clone() zwraca -EFAULT lub -EINVAL, jeśli jest z nimi jakiś problem.

Obecny kod nie jest zmieniany przez te nowe flagi. Łatka została przetestowana na 2.5.31-BK-obecne.

Linus, jestem ciekaw, czy łatki NFSv4 zostaną zaakceptowane w najbliższej przyszłości (np. przed 2.6).

Chciałbym SZCZEGÓLNIE zobaczyć jedną łatkę z NFSv4 (mówię konkretnie o Kerberized NFSv4). Właśnie zakończyłem wdrażanie solarisowego środowiska Kerberized NFS z katalogami domowymi automatycznie montowanymi przez klientów używających ,,silnego'' uwierzytelniania użytkownika.

Szczerze mówiąc, podstawowy (bez obsługi Kerberosa) model bezpieczeństwa NFS jest do kitu.

Fakt, iż woźny z laptopem (lub jakikolwiek klient obsługiwany przez złośliwego administratora systemu) może naruszyć integralność katalogów domowych ze standardowego serwera katalogów domowych, strasznie mnie irytuje.

Ok, rzecz pierwsza, uwierzytelnianie z serwerem oraz pobranie klucza kryptograficznego do celów uwierzytelnienia. To rozwiązuje problem złych klientów. Kerberos, gssapi itp. już się tym zajmą.

Rzecz druga, to błąd obsługi stron pamięci podręcznej w NFS. W NFS współdzielenie dostępu do pamięci podręcznej jest zabronione, chyba, że użyto tego samego uwierzytelnienia dla zapytań. Wszystko co możemy (i powinniśmy) zrobić w przypadku, gdy wydaje nam się, że możemy ponownie użyć wpisu w tej pamięci, to wykonać sprawdzenie NFS ACCESS dla NFSv3, a dla NFSv2 -- odesłać go do serwera, jeżeli jest niepoprawny, a następnie odczytać nowy zestaw uwierzytelnień.

Jeżeli znajdzie się dobre wytłumaczenie, poparte dobrymi argumentami, iż nie będzie problemu, co do eksportu tych technologii, to nie sądzę już, że jest to niemożliwe.

Jednakże, dobre wytłumaczenie musi być lepsze niż tylko twierdzenie, że jest to ,,rzecz technicznie doskonała, lecz niezbyt rozpowszechniona''.

Tak szczerze - osobiście podejrzewam, że kryptografia zostanie najpierw dodana do jąder rozpowszechnianych razem z dystrybucjami - jeżeli twórcy tych dystrybucji zechcą rozważyć zagadnienia dotyczące eksportu wspomnianych technologii, to bardzo dobrze, jeżeli zaś nie, to standardowe jądro tego na nich nie wymusi.

Osobiście wątpię, by NFS doprowadziło do takiego stanu. Opierając się na doświadczeniach z przeszłości, kłopoty z bezpieczeństwem NFS nie są zbyt wielkim problemem dla ludzi. Przypuszczam, że dla nich ważną rzeczą będzie dodanie przez producentów dystrybucji VPN lub szyfrowanych (lokalnie) dysków.

Sądziłem, że będzie duża presja na włącznie IPSEC, jako, że to tworzy nowe ,,efekty sieciowe'', lecz jest to ciągle powstrzymywane przez polityków. Sądzę, że czekają na pisemne zaproszenie, lub coś w tym stylu.

Czy interfejs lokalny jest wystarczająco stabilny, by dodać do niego obsługę szyfrowania? Przyszło mi na myśl, że lepiej będzie, gdy przeniesiemy zaczepy translacji do ogólnej warstwy blokowej, aby rzeczy, takie jak LVM i iSCSI oraz kompletnie idiotyczne w swym zamyśle ,,bit-swapped ide'' mogły korzystać z ich dobrodziejstw bez użycia skłonnych do blokowania się funkcji interfejsu zwrotnego. Jakieś pomysły?

Nie jestem pewien, która warstwa powinna się tym zajmować. _Nie_ jest zupełnie jasne, czy powinna to być warstwa blokowa i nawet jeżeli potrzebujesz tam zaczepu, to podejrzewam, iż wyższe warstwy zechcą przesyłać dane kontekstowe do warstwy szyfrującej.

W szczególności, posiadanie globalnego mechanizmu bezpieczeństwa dla dysków może wcale nie być tak dobrym pomysłem - możesz mieć życzenie, by posiadać informację dla każdego pliku z osobna, a to powoduje, że warstwa blokowa nie może obsługiwać tego sama, a wyższe warstwy muszą przekazywać różne klucze użytkownika w zależności od operacji.

W innych sytuacjach, odpowiednie warstwy są same w sobie strumieniem (np. ,,NFS over SSH/Kerberos'' jest tego typu rzeczą), lecz to podejście zakłada, że ufasz drugiemu końcowi połączenia. Jeżeli tak nie jest, to wracasz do punktu, w którym koniecznością stanie się szyfrowanie odnoszące się do każdego pliku z osobna (prawdopodobnie, jako _dodatek_ do szyfrowania strumieniowego), co w końcu implikuje fakt, iż potrzebujesz szyfrowania albo na poziomie pamięci podręcznej stron, albo na poziomie obecnego API.

(Poziom API jest, oczywiście, ukierunkowany na oprogramowanie go razem z bibliotekami dołączanymi z przestrzeni użytkownika, więc, być może, nie będzie potrzeby obsługi tego ze strony jądra systemu. Obsługa tego przez jądro może nie być pożądana, nawet jeżeli szyfrowanie jest realizowane przez programy użytkownika)

Oddzielnie od właściwego szyfrowania mamy zarządzanie kluczem. Nawet jeżeli jądro nie miałoby realizować żadnych zadań związanych z szyfrowaniem (podejście takie, jak z bibliotekami na poziomie użytkownika), podejrzewam, że część ludzi chciałaby mieć obsługę stanu posiadania kluczy w obrębie procesu.

A TO, podejrzewam, jest jednym z większych powodów, dla których nie ma rozbudowanej infrastruktury kryptograficznej w jądrze. Jest zbyt wiele możliwości wyboru, różni ludzie potrzebują różnych rozwiązań - w rezultacie czego infrastruktura jest, dosłownie, wszędzie.

Niewątpliwie, niektórzy ludzie ufają swoim serwerom i chcą mieć pewne połączenie oparte na sieciach WAN, gdy łączą się z nimi. Inni nie ufają nawet LAN-om, czy nawet samej zawartości serwerów i chcą mieć zabezpieczenia odnoszące się do konkretnych plików. Oba te podejścia posiadają dobre strony. To mówi nam, że nie ma ,,zaczepu''. Jest ,,labirynt zaczepów, różniących się szczegółami''.

Teraz, gdy wszystkie elementy są na swoim miejscu, ta wielka łata wprowadza cały nowy kod dla serwera NFSv4.

Ta łata nie wprowadza praktycznie zmian w obecnym, głównym kodzie nfsd (ten zostanie uaktualniony w nadchodzących łatkach).

Jeden aspekt NFSv4 zasługuje na komentarz. Najbardziej naturalnym schematem przetwarzania zapytań COMPOUND wydaje się być następujący wariant:

1a. faza detekcji XDR, detekcja argumentów dla wszystkich operacji
2a. faza przetwarzania, obsługa wszystkich operacji
3a. faza kodowania XDR, kodowanie wyników wszystkich operacji

Jednakże, używamy schematu, który działa następująco:

1b. faza dekodowania XDR, detekcja argumentów dla wszystkich operacji
2b. Dla każdej operacji,
przetwarzanie operacji
kodowanie wyniku

Aby dostrzec, co jest złego w pierwszym podanym schemacie, przyjrzyjcie się COMPOUND w postaci READ REMOVE. Ponieważ ostatni bit przetwarzania dla zapytania READ występuje w kodowaniu XDR, w kroku 3a możemy zauważyć, iż zapytanie READ powinno zwrócić informację o błędzie. W takim przypadku, zapytanie REMOVE nie powinno być w ogóle przetwarzane, ponieważ REMOVE zostało już wcześniej zrealizowane w kroku 2a!

Inny typ problemu wystąpi w COMPOUND w postaci READ WRITE. Załóżmy, że obie operacje zakończyły się pomyślnie. Biorąc pod uwagę schemat a, WRITE jest wykonywane _przed_ READ (podczas gdy ,,prawdziwy'' READ jest wykonywany w trakcie kodowania XDR). To jest oczywiście niepoprawne, jeżeli zakresy READ i WRITE nakładają się.

Te wyjaśnienia mogą wydawać się trochę sztuczne, lecz wydaje się również, że do prawidłowej obsługi COMPOUND we wszystkich przypadkach, musimy używać schematu (b), zamiast schematu (a).

(Aby stworzyć mniej sztuczne przykłady, zamień READ na GETATTR w powyższych przykładach. To zadziała, ponieważ ,,prawdziwe'' GETATTR jest wykonywane podczas kodowania XDR: niektórzy naprawdę chcieliby powrócić do starego stanu, aby napisać rzeczy inaczej.)

Mam lepszy pomysł. Co sądzicie o przekształceniu write(2) tak, by pisząc do /dev/console, zachowywało się jak printk()? Innymi słowy, co sądzicie o tym, by wszystko, co jest zapisywane do /dev/console pojawiało się w dmesg?

W ten sposób uniknęlibyśmy tworzenia czegoś specjalnego na potrzeby logowania _oraz_ mielibyśmy przechwycone wyjście skryptów inicjalizacyjnych. Za darmo. dmesg(8) przejęłoby to wszystko, klogd(8) pracowałoby jak teraz, itp.

Mam nadzieję, że to zmniejszy liczbę pytań typu ,,co znaczy ten oops?'' i ,,co powinieniem zgłosić?'' na l-k. Obejmuje wszystkie architektury, jest testowane jedynie na i386, ale jest ,,w sposób oczywisty poprawne'' (mhm, jassne!).

Wypisuje ,,Przeczytaj Documentation/oops-tracing.txt przed zgłoszeniem tego problemu'' przed oopsem, zakleszczeniem nmi itp. Jeśli ktoś utrzymuje bazę błędów, nie mam nic przeciwko, aby zmienić komunikat tak, aby wskazywał tę bazę.

Przykro mi, że was rozczaruję, lecz szanse na włączenie tego do głównej linii jądra są nikłe z następujących powodów:

1. Nowe płyty główne mają wbudowane karty dźwiękowe, może niezbyt cudowne, lecz na pewno lepsze, niż pecetowy głośniczek.
2. Standaryzacja w dziedzinie pecetowego głośniczka jest niewystarczająca. Jest on stworzony do ,,bipkania'' i żaden z producentów płyt głównych nie przeprowadza testów mających na celu polepszenie parametrów częstotliwościowych. Jako, że mogą być one tworzone wg różnych schematów, nie można być pewnym, w jaki sposób uzyskać maksymalną amplitudę na konkretnej płycie głównej (są 2 czy 3 różne sposoby uzyskiwania maksimum dla różnych płyt głównych. W każdym razie jakoś tak, przynajmniej wg artykułu, który przeczytałem dawno temu w jakimś magazynie).
3. Występuje nienormalnie duże obciążenie procesora. A nawet więcej, ponieważ niektóre obecnie produkowane płyty główne emulują głośniczek za pomocą wbudowanych kart dźwiękowych oraz trybu SMM (ick).

Uruchomiłem nastepujący skrypt lots_of_forks.sh dla kilku wersji jądra.

http://people.nl.linux.org/~phillips/patches/lots_of_forks.sh

używając time -v sh lots_of_forks.sh

Wyniki dla 2.4.20-pre2 oraz 2.4.20-pre2-ac1 bardzo się różnią.

2.4.20-pre2:
Command being timed: "sh lots_of_forks.sh"
User time (seconds): 18.15
System time (seconds): 24.96
Percent of CPU this job got: 181%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:23.71

2.4.20-pre2-ac1:
Command being timed: "sh lots_of_forks.sh"
User time (seconds): 28.04
System time (seconds): 53.18
Percent of CPU this job got: 187%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:43.32

Uruchomiłem ten test ośmiokrotnie, jeden po drugim, bez żadnych przerw pomiędzy nimi. Poniższe liczby to czas systemu jaki zwracało polecenie time -v. Testowym komputerem był dwuprocesorowy p3, jądra miały włączoną obsługę SMP, były identycznie skonfigurowane, a w /proc/sys/vm nie dokonywano żadnych zmian.

        2.4.20-pre2     2.4.20-pre2-ac1 2.5.28          2.5.31

1       24.96           53.18           39.91           37.04
2       24.92           52.42           44.91           45.88
3       24.69           50.69           48.63           44.89
4       24.39           51.9            58.12           55.8
5       24.72           46.14           49.81           43.18
6       24.34           47.99           57.62           40.93
7       24.64           52.33           50.42           47.27
8       24.53           52.84           45              36.49

Testy te mogą być niesprawiedliwe, aczkolwiek mogą wskazać dalsze drogi poszukiwań.

Sądzę, że to może być problem. Rmap daje dużą przewagę w wielu zastosowaniach, lecz nie jest dobrym wyborem dla testowania czasów forkowania procesów. Podstawowym pytaniem jest: czy fork-bomby dominują przy obciążaniu Twojego systemu oraz gdzie jest odpowiednia granica pomiędzy nieprzewidywalnym zachowaniem VM i mniejszymi kosztami przeprowadzanych obliczeń?

Nie ma jednoznacznej odpowiedzi.

wyniki testów:

        2.5.31-vanilla  2.5.31-akpm-all
1               37.04           35.98
2               45.88           36.94
3               44.89           35.23
4               55.8            38.49
5               43.18           51.43
6               40.93           46.3
7               47.27           46.94
8               36.49           47.19

Chciałem z dumą ogłosić: (a także podarować sobie mały prezent urodzinowy :)

WOLK v3.5 FINAL, Nazwa kodowa ,,Fin'' vel ,,Wydanie urodzinowe''

Zostało wykonanej wiele pracy od poprzedniej wersji WOLK, v3.4.

Jestem też dość zadowolony, że jest to ostatnia wersja ,,Działającego Przeładowanego Jądra Linuksa'' (,,Working Overloaded Linux Kernel''), ponieważ nie mam czasu, którego WOLK potrzebuje do dalszego rozwoju. Mam pracę, dziewczynę, kilku przyjaciół etc., więc zależę od kilku osób, które pomogą mi w zarządzaniu projektem.

Tysiące razy prosiłem o pomoc, dostałem kilka propozycji, ale nigdy nie doszło do realizacji tych obietnic. Jedynymi prawdziwie pomocnymi rękoma były ręce Michaela Gasperiego, jedynego współtwórcy mojego projektu, oraz Dominika Prepeeta, mojego ,,osobistego'' Guru C/C++ ;). I jeszcze 2 razy Jure Pecar... Ale 2-3 osoby to zdecydowanie za mało, aby porządnie kierować tak dużym projektem.

W każdym razie było fajnie, miło spędzałem czas, miałem dobre jądro, nauczyłem się wiele na temat jądra. Wielkie dzięki dla wszystkich ludzi na tej planecie, używających WOLK.

Niestety nie udało mi się, jak planowałem, włączyć OpenMosix i schedulera O(1)!

Myślę, że to wspaniale, iż ludzie podpisują swoje listy za pomocą GPG/PGP (sam zacznę je w ten sposób podpisywać, jak tylko będę miał odpowiednie łącze w domu i nie będę musiał wysyłać listów e-mail ze zdalnego serwera, na którym nie chcę przechowywać mojego klucza prywatnego), lecz kiedy publiczne klucze są niedostępne, trudne do zdobycia lub nieważne z jakiegoś powodu, podpisywanie poczty staje się bezużyteczne.

Monitorowałem użycie podpisów na liście przez ostatnich kilka miesięcy i przedstawiam listę osób, których sygnatur nie byłem w stanie odnaleźć. (nie były dostępne na wwwkeys.pgp.net, a nagłówki listów nie posiadały pól x-pgp czy x-gpg z podaną lokalizacją tych kluczy):

Justin Carlson          C1A06FBE
Florent Chabaud         95C81C3C
Thomas Duffy            38F3C1BC
David Fries             CB1EE8F0
Roger Gammans           88DE0B3E
Austin Gonyou           59853282
Josh Litherland         893D9228
Brandon Low             1F012DC6
John L. Males           99ED3565
Brendan W. McAdams      82306710
Solomon Peachy          2DBBE7D0
Joe Radinger            F957E8F3
Udo A. Steinberg        233B9D29
Gianni Tedesco          8646BE7D
Martin Waitz            DFE80FB2
Derek James Witt        972FE938
Wiktor Wodecki          A1559FE7
Pete de Zwart           984AF710

Dodałem wszystkich z powyższej listy do bcc.

Dla tych, którzy nie wiedzą jak wysłać swój klucz publiczny na publiczny serwer, podaję rozwiązanie:

gpg --keyserver wwwkeys.pgp.net --send-keys <keyid>

Znalazłem klucze publiczne nastepujących osób na search.keyserver.net (podziękowania dla Rogera Gammansa za wskazówkę!);

Brandon Low
Solomon Peachy
Pete de Zwart
Gianno Tedesco (wydaje się, że ma ,,zepsutego'' klienta pocztowego; sygnatury jego listów są ZŁE, przynajmniej wg mutt/gnupg v1.0.7)
Roger Gammans

Teraz zalecenie:

dodajcie

x-gpg-fingerprint: <fingerprint>
x-gpg-key: <url do Twojego klucza lub serwera kluczy>

do nagłówków listów.

Ta łatka to dokumentacja JBD w DocBooku, którą obiecywałem już od dłuższego czasu ;-).

Aplikuje się na 2.4.20-pre2.

Andrew, jeśli wolisz, aby aplikowała się na jakąś inną wersję, daj mi znać.

Strona projektu: http://www.csn.ul.ie/~mel/projects/vmregress/

Ściągać można z: http://www.csn.ul.ie/~mel/projects/vmregress/vmregress-0.5.tar.gz

Oto druga publicznie udostępniana wersja VM Regress. Są to początki narzędzia do testów regresyjnych i porównawczych VM w Linuksie. Strona w sieci zawiera wstęp, a sam projekt zrozumiałą dokumentację i komentarze. To ciągle bardzo wczesne stadium.

Ta wersja zawiera dużo poprawek spójności infrastruktury całości, pełną listę zmian zamieszczam na końcu. Nie chcę zanudzić ludzi szczegółami, ale całość jest w lepszej kondycji. Są dwie nowe poważne rzeczy, które warto zauważyć.

1. Wypisywanie mapy stron obecnych w pamięci i na dysku. Moduł pagetable może teraz wypisać taką mapę, która reprezentuje strony w pamięci adresowej, na końcu testu. To oznacza, że gdy uruchamiamy test odwołujący się do stron, to można *dokładnie* zobaczyć, jak wygląda przestrzeń adresowa po uruchomieniu testu. Rozważam rozszerzenie tego do wypisywania przestrzeni adresowej dowolnego procesu, ale nie jestem pewien, czy byłoby to użyteczne. Być może wygodnie by było uruchamiać skrypt powłoki stworzony ad hoc, mając odpowiedni moduł związany z procesem, który wypisałby jego przestrzeń adresową przed jego zakończeniem, żeby zobaczyć jak wyglądała na końcu...
2. Dostarczony jest skrypt plot_map.pl, który bierze testowe wyjście, które zawiera mapę (obecnie tylko fault.o) i produkuje stronę internetową z nią. Pod adresem http://www.csn.ul.ie/~mel/projects/vmregress/output_sample/test_fault_zero.html można zobaczyć przykładową stronę. Rysunek pokazuje przetestowaną przestrzeń adresową. Gdy test się skończył, to cały proces został zrzucony na dysk, zatem wszystkie strony na początku były na partycji wymiany, a późniejsze ciągle w pamięci. Oczekuję, że późniejsze testy pokażą, jak dobrze wygląda to przy rmap w porównaniu ze starszymi jądrami. Późniejsze testy będą miały też bardziej interesujące wzorce odwołań niż proste, liniowe odwoływania.

Następną rzeczą do dodania do wyników jest uwzględnienie sztucznego licznika odwołań do stron. Dla danego testu nagrywana jest liczba odwołań do strony, która to liczba posłuży do porównania ze stronami obecnymi w pamięci. To powinno pomóc określić, czy Linux umie wybrać strony, które powinny pozostać w pamięci, czy nie. Od tego miejsca pisane testy będą zawierać różne wzorce odwoływań i różne typy pamięci, takie jak mmapowane pliki i tak dalej.

Cechą mniej istotną są początki umożliwienia przeglądania obszaru vmalloc. W tej chwili wypisze on tylko rozmiary. Większość pozostałych rzeczy składa się na zrzut pamięci.

Tak jak poprzednio, narzędzie nie dostarcza jeszcze wszystkich odpowiedzi, ale jest na bardzo wczesnym etapie, a gdyby to było do zrobienia szybko, to już bym to zrobił :-) . Mam nadzieję, że w końcu będę umiał odpowiadać na większość pytań odnośnie VM.

Lista zmian tej wersji jest następująca....

Wersja 0.5

• Dodałem moduł kvirtual, wypisujący przestrzeń adresową vmalloc
• Można przekazywać wskaźnik danych klienta do funkcji przechodzących po tablicy stron
• Bufory proc są przechowywane w strukturze vmr_desc_t struct
• Bufory proc mogą rosnąć
• Można wypisać mapy procesu, żeby zobaczyć obecne/przerzucone na dysk strony
• Stworzyłem plot_map.pl, które stworzy rysunek stron obecnych w pamięci i przerzuconych na partycję wymiany
• Dodałem do plot_map.pl opcję do produkowania na żądanie stron html z wynikami
• Uaktualnienie łatki na jądro do wersji 2.4.20pre2 . Powinno nakładać się na 2.5.x

Wszystkie komentarze będą mile widziane.

Chłopaki, mamy tutaj pewien problem w schedulerze i/o 2.4. Podstawową rzeczą jest to, iż zliczanie w 2.4.20-pre2 jest niepoprawne.

Liczniki dla żądań są zmniejszane, jak tylko scheduler we/wy ,,przejdzie'' nad nimi w poszukiwaniu punktów ,,scaleń'' lub ,,wstawień''. Jeżeli nie zostanie znalezione nic do scalenia, całkowity skan zostanie zakończony, a co za tym idzie wszystkie liczniki żądań zostaną zmniejszone o 1. Tak więc, żądania będące przed punktami scaleń są tak samo ,,karane'' jak te, znajdujące się za tymi punktami. Jeżeli punkt scalenia zostanie znaleziony, ll_rw_blk.c wywoła funkcję przemieszczającą merge_cleanup, która ,,podliczy'' scalenie poprzez zmniejszenie sekwencji żądań za punktem scalenia o zawartość sektora używanego bufora. W rezultacie przeszukiwanie ,,karze'' wszystkie żądania kosztem równym 1, a scalanie karze następne żądania kosztem zawartości sektora + 1, zazwyczaj o 9.

Kompletny śmietnik. Nie wiem, gdzie zawodzi logika, lecz podsyłam łatkę, która to naprawia. Robi dwie rzeczy:

• Zlicza scalania kosztem 1, a wyszukiwania kosztem 16. Obecne wartości nie są zbyt ważne, tutaj jedynie wskazują, że koszt wyszukiwania jest 16 razy większy niż koszt scalania. Obecny koszt scalania nie jest zbyt ważny, ponieważ rozmiar żądania jest skończony. Oznacza to, iż unieważniamy starą wartość elvtune dla funkcji przemieszczającej. Wybrałem 2048 dla odczytów oraz 8192 dla zapisów, co oznacza maksymalnie ~128 wyszukiwań na jeden odczyt (oraz ~512 na zapis).
• Ciągle pozwala na scalanie, nawet jeżeli przekraczamy punkt zerowy w sekwencji listy sortującej. Jest to zrobione przy założeniu, że scalenia są generalnie ,,wolne'', patrząc na nie z punktu widzenia dysku.

Obecne wartości prawdopodobnie potrzebują nieco dostrojenia. Byłbym bardzo wdzięczny wszystkim za sprawdzenie, jakie wartości dają dobrą przepustowość przy testach, a jakie zapewniają rozsądne opóźnienia na stacjach roboczych.

Marcelo, proszę Cię o włączenie łatki do 2.4.20-pre2

Myślałem o zrobieniu tego, od kiedy istnieje tekstowa pomoc do procesu konfiguracji jądra. Większość zmian to zastąpienie ,,powiedzieć'' przez ,,zaznaczyć'' (z uwzględnieniem odmiany), ponieważ choć istnieje wiele różnych sposobów konfiguracji jądra, to rozpoznawanie mowy jeszcze do nich nie należy. :) Próbowałem poprawić też gramatykę tak, jak tylko umiałem i uczynić ją bardziej konsekwentną. Ponieważ już się za to zabrałem, połamałem też niektóre zbyt długie linie.

Łatka nakłada się na 2.4.19 i jest dostępna pod http://www.geocities.com/kevin_burtch/config.patch.gz (nie chciałem jej tu wysyłać, bo to ponad 1MB nieskompresowanego tekstu)

Nie widziałem większości jego pracy, ale to mi wygląda na smutny dzień dla Marcina, który poświęcił wiele swego czasu na pracę nad tymi rzeczami, podczas gdy inni nie tylko nie byli za to wdzięczni, ale jedynie pokrzykiwali na niego, nie dotykając się kodu w ogóle. To musi boleć.

Czy jest jakiś sposób, aby poprawki, które już weszły, przeżyły? Albo przynajmniej wiedza, która może zostać użyta wprost w sterowniku IDE-TNG? Naprawdę sądzę, że to smutne, iż tyle czasu zainwestowanego w projekt przepadnie -- ale pamiętajcie, że NIC nie wiem na temat szczegółów ostatniego sterownika IDE w 2.5.

Podam Wam, chłopaki, IDE-TNG na srebrnej tacy.

Poniżej przedstawiłem modularną rejestrację chipsetów i indeksów kanałów. Wybieralne IOPS-y dla niezależnych od architektury warstw Transportowych Plików Zadań (Taskfile Transport layers). Muszę jeszcze skończyć pracę nad listami klas urządzeń, aby wykorzystywały w pełni modularne podsterowniki. Macie też pierwszą generację wywołań open i select sterownika w podsterownikach.

Masz zarejestrowany ide-cd na cdrw i chcesz wypalić płytkę?
open(/dev/hdX) transform_subdriver_scsi close(/dev/hdX)
open(/dev/sg) i wypalaj.
close(/dev/sg) zwalnia transform_subdriver_scsi
open(/dev/hdX) ładuje natywny transport atapi.

Przepraszam, ale nie mogę się powstrzymać do śmiechu :P

Wyobrażam sobie, o czym marzysz. Jak: ,,kurde, k*rwa, dlaczego kurde wykopałem Andre Hedricka, dlaczego kurde powiedziałem mu żeby utopił się w klozecie?!!?''

Przepraszam, ale nie mogłem się powstrzymać. ;)

Wyrzucenie w cholerę wielu miesięcy pracy, czy poddanie się po wielomiesięcznej pracy NIE JEST ŚMIESZNE.

Jestem wdzięczny Marcinowi za to, że probował poprawić warstwę IDE.

Jego metoda usuwania różnych rzeczy, aby ,,później stworzyć lepszą implementację'' nie zawsze okazywała się skuteczna, ale jestem mu wdzięczny za to, że próbował.

Nie, nie wyobrażasz sobie.

Marzę o opiekunie IDE, z którym ludzie (włączając w to zwłaszcza mnie) potrafią pracować. Nie wiem dlaczego, ale od pewnego momentu IDE stało się bardzo trudnym obszarem i przysparza opiekunom o wiele więcej bólu głowy niż cała reszta jądra razem wzięta..

Było już raz całkiem gładkie przekształcenie IDE (oryginalne przekształcenie z hd.c do ide.c) i nazywanie tego ,,gładkim'' jest raczej oceną post factum -- w momencie dokonywania zmiany wszyscy myśleli, że to strasznie głupie nie pozwalać na duże i kontrowersyjne zmiany w hd.c, a wynikowa duplikacja kodu została okrzyknięta katastrofą.

W tej chwili wygląda na to, że Alan chce przez jakiś czas popracować nad kodem IDE, co bardzo mnie cieszy. Tylko zastanawiam się, jak długo to wytrzyma (utrzymywał różne listy błędów w IDE przez lata, więc można mieć nadzieję).

Prehistoria: Linus i inni.

Od początku 1994: Mark Lord. Wszyscy byli szczęśliwi do połowy 1998 (2.1.111), gdy po dyskusji na temat problemów z DMA, których doświadczyło kilka osób, Linus zmienił linux/drivers/block/Config.in:

-        bool '     Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA
+       # Either the DMA code is buggy or the DMA hardware is unreliable. FIXME.
+        #bool '     Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA

a Mark powiedział: ,,Nie będę więcej aktualizował sterownika IDE, dopóki plik linux/drivers/block/Config.in nie zostanie przywrócony do wersji sprzed 111.''

Od końca 1998 (2.1.122): Andre Hedrick.

Ostatnia historia jest znana.

(Wiele innych osób również czynnie pomagało przy IDE. Nie będę nawet próbował wymienić ich wszystkich, ponieważ na pewno bym kogoś pominął.)

Oczywiście ,,opiekun IDE'' oznacza pracę nad interfejsem do sprzętu i pracę nad interfejsem do podsystemu blokowego WE/WY w jądrze. Niektóre osoby wiedzą wszystko na temat sprzętu, inne niewiele na temat sprzętu, ale za to doskonale znają interfejs sterowników. Nie ma powodu, aby ,,opiekun IDE'' był za wszelką cenę pojedynczą osobą.

Tego nie ma w teorii, ale ponieważ mała zmiana w jednej części spowoduje, że inne sterowniki przestaną działać, to musi istnieć wybrana osoba, która trzyma to wszystko w kupie. I to _będzie_ ta osoba, do której będzie można się zwrócić, gdy coś przestanie działać.

To jest przypuszczalnie jeden z najważniejszych powodów ,,choroby IDE''. Objawem choroby jest to, że ludzie narzekają na to, że nic nie działa, a opiekun robi się na tyle zdołowany zarzutami, że przestaje mieć kontakt z rzeczywistością i zaczyna zajmować się względami zgodności z dokumentacją, mając nadzieję, że to wszystko naprawi.

To by było wszystko fajnie, tylko że większość problemów nie jest związana z rzeczami w dokumentacji, a ze sprzętem, który nie jest opisany w specyfikacji i trzeba stosować różne obejścia itp. Więc, gdy już zacznie się choroba ,,jest zrobione tak, jak opisano w dokumentacji i jeśli nie działa, to Twój komputer jest uszkodzony'', to już spadamy na łeb, na szyję.

Twierdzę, że to się zdarza również dla innego sprzętu, ale przy innym sprzęcie nie ma takich naszłości (ludzie w końcu wyrzucają podstawowy kod i zaczynają nowy bez historycznych śmieci) i połączenia pomiędzy sterownikami nie są obecne aż w takim stopniu. Gdy deweloper może pracować z jednym tylko chipsetem, jest możliwe, że mu się uda. Ale, gdy zaczynasz być obwiniany za wszystkie problemy IDE, zbierasz swoje zabawki i idziesz do innej piaskownicy.

Dlatego właśnie sądzę, że jedynym sensownym owocem pracy nad IDE może być powstanie niezależnych sterowników, co najprawdopodobniej pociągnie za sobą duplikację kodu (tak, jak hd.c i ide.c rozpoczęły współistnienie z duplikacją dużej ilości kodu), ale będziemy mieli sytuację, gdzie wiele osób _będzie_mogło_ odpowiadać za swoje sterowniki (i będzie jasne, _czyim_ problemem jest to, że jakiś kontroler IDE nie działa).

(Część infrastruktury może być rzeczywiście ogólna, ale ta ogólna część może zawierać _jedynie_ rzeczy, które naprawdę są niezależne od sprzętu i _nie_mogą_ mieć na nią wpływu różne sztuczki i błędy związane z implementacją sprzętową. W skrócie, mogą się tam znaleźć jedynie rzeczy, o których można dyskutować na logicznym poziomie i reguły są tam ustalane przez nas, a nie przez wykręcony sprzęt).

Nie sądzę, aby to była w zbyt dużym stopniu wina ludzi, ale raczej bezsensownych połączeń wewnątrz ide.c i strasznie skomplikownych reguł. Kod jest niejasny.

Sterowniki sieciowe mają różne konfiguracje z tymi samymi chipsetami, ale raczej są to osobne sterowniki współdzielące różne funkcje pomocnicze. Każdy sterownik osobno wykonuje rejestrację sterownika PCI itp. W przeciwieństwie do tego, w IDE sterownik w pierwszej kolejności jest sterownikiem IDE, a dopiero w drugiej kolejności sterownikiem chipsetu PCI i taka zamiana wag powoduje problemy.

Nawet coś tak prostego, jak sterowniki PIIX (które _powinny_ się po prostu zarejestrować jako sterowniki dla chipsetów piix) nie robią tego. Zamiast tego mamy ide-pci.c, które ma listę wszystkich znanych sobie układów i następnie wykonując inicjalizację, wywołuje funkcje inicjalizujące, o których wie. To po prostu kazirodztwo.

A wszyscy wiemy dokąd kazirodztwo prowadzi. Do dziedzicznego obłędu.

IMHO potrzebujesz

• Zrozumienia ATA (które jest protokołem równoważnym zorientowanemu obiektowo cobolowi)
• Możliwości pracy z producentami sprzętu (to musi być ktoś reprezentujący jakąś firmę, ponieważ wielu producentów nie podpisuje NDA (Non Disclosure Agreement) z osobami prywatnymi, nawet jeśli nie mają nic przeciw kodowi GPL na podstawie dostarczonych danych)
• Umiejętności ładnego programowania i umiejętności doprowadzenia kodu do ładu bez psucia go
• Umiejętności wydedukowania listy błędów, której nie dostaniesz od producenta, bo albo zapomni Ci o niej powiedzieć, albo z obawy przed amerykańskimi prawnikami nie chce przyznać, że takowa istnieje
• Dobrego zrozumienia warstwy blokowej i zastosowanego tam blokowania, ponieważ w IDE mamy problemy następujących kategorii:
• dwa napędy na jednej magistrali
• dwa kanały na jednym silniku DMA
• dwa kontrolery z jednym WE/WY w danej chwili
• blokady współdzielonych IRQ dla ISA

Uwaga: to też _jest_ wina ludzi, ale nie zrozumcie mnie źle. W innych obszarach mamy takich ludzi, jak Al Viro, którzy swoimi niezbyt przyjaznymi mailami sprawiają, że dorośli ludzie zaczynają płakać (i pić). I w tych obszarach nie ma z tym zbyt dużego problemu, nawet jeśli to sprawia, że niektórzy muszą wziąć valium na dzień czy dwa przed tym zanim odważą się otworzyć e-maile od Ala.

A więc bałagan i system połączeń warstwy IDE po prostu sprowadza problem czynnika ludzkiego do paskudnego punktu. Absolutny brak komunikatywności pośród ludzi pracujących nad IDE był pierwszorzędny i prawdopodobnie _jest_ to spowodowane faktem, że kod jest zbyt ciężki, aby o nim dyskutować.

Uech... To, czego potrzebujemy w IDE, to

1. tłumacz/filtr przekłamań pomiędzy ludźmi od sprzętu, a całą resztą. Jeśli Jens albo Alan chcą przez chwilę być takim kimś, to wspaniale.
2. przegląd struktury istniejącego kodu. Robimy to.
3. ostrożny masaż (w przeciwieństwie do całkowitego przepisania) wspomnianych struktur

tak, aby otrzymać coś sensownego. Przy pomocy serii małych przekształceń, gdzie będziemy mogli udowodnić, że nie zmieniają znaczenia kodu. I ktokolwiek podejmie się tego, narazi się na spalenie na stosie -- to spagetti, które mamy, to cholerny bałagan. Spróbuję pomóc przy tym -- wiem, jak wykonać taką pracę, ale nie obiecuję asystować przy tym aż do końca.

Gdy już będziemy mieli sensowną strukturę i sensowne interfejsy, życie stanie się prostsze. Do tego momentu, opieka nad drivers/ide/* w pełnym wymiarze, to bilet w jedną stronę do Koziej Wólki.

Osobiście sugerowałbym alternatywne (ale nie tak bardzo różne) podejście.

Podejście, za którym się opowiadam wygląda tak

• usunięcie rejestracji głównych numerów z kodu IDE i zmiana wszystkich numerów urządzeń na indeksy oraz kolejkę. To może być wykonane bez żadnych zmian w WE/WY wykonywanym przez sterowniki i powinno być możliwe do wykonania przy pomocy przekształcenia, które _w_ogóle_ nie zmienia zachowania.

  Tak przy okazji, to jest to obszar, z którym pewien Al jest dość dobrze zaznajomiony ;)

• gdy już sterowniki IDE nie będą nic wiedziały o głównych i pobocznych numerach (wydaje mi się, że mają teraz przypisanych 10 głównych numerów) i nie będą rejestrowały urządzenia blokowego przy pomocy ,,register_blkdev()'', ale za to będą rejestrowały, za pomocą jakiegoś pośredniczącego agenta, pojedynczo kontrolery, możemy przejść do fazy 2.

• faza 2: IDE-TNG. Zostawiamy obecny kod IDE nieruszony i planujemy go wywalić w przyszłości. To jest ,,stabilne IDE'' i przez tę cechę bycia stabilnym, nikt nie będzie miał nic przeciwko nowym sterownikiom, które (z definicji) nie będą mogły nic zepsuć, o ile nie będzie się ich stosować.

  IDE-TNG mogłoby:

  • być skoncentrowane na kontrolerze (tzn. jeden sterownik na jedną rodzinę kontrolerów)
  • być w stanie powiedzieć ,,olej to'' dla starych albo złych konfiguracji, które byłyby zostawione dla starego kodu IDE)
  • zajmować się w szczególności jedynie kontolerami PCI (albo lepszymi) i jedynie konfiguracjami UDMA.

Celem IDE-TNG byłaby jedynie obsługa głównych kontrolerów we wspomniany przeze mnie sposób, ale niech te główne kontrolery mają sterownik, który jest przeznaczony dla _nich_ i nie jest obarczony zaszłościami historycznymi.

A potem, za pięć lat, w Linuksie 3.2, będziemy mogli w końcu zrezygnować ze starego kodu IDE obsługującego PIO itp. Niewątpliwie będą istnieć jeszcze różne osoby, które będą tego używać (tak jak istnieją osoby, które używają Linuksa 2.0 z hd.c), ale to nie stanie na przeszkodzie w stworzeniu ładniejszego sterownika w międzyczasie.

I tak, w tej chwilo, to się zdecydowanie nadaje dopiero do 2.7.x.

Ta łatka dodaje obsługę SMP (i UP) dla voyagera, który jest mikrokanałową architekturą SMP (do 32 procesorów) nie-PC.

Jedyną zmianą od 2.5.31 jest to, że będzie się uruchamiać z niezerowym identyfikatorem procesora butującego (poprzednio current->cpu było inicjalizowane zbyt późno).

Łata składa się z dwóch części: kawałek podarchitektury i386 jest oddzielony od dodatkowych komponentów voyagera

http://www.hansenpartnership.com/voyager/files/arch-split-2.5.31.diff (108k)

http://www.hansenpartnership.com/voyager/files/voyager-2.5.31.diff (146k)

Musicie zaaplikować łatkę split zanim zaaplikujecie tę drugą.

Obie łatki są dostępne, jako oddzielne drzewa bitkeepera (drzewo voyager jest nadzbiorem drzewa arch-split):

http://linux-voyager.bkbits.net/voyager-2.5

http://linux-voyager.bkbits.net/arch-split-2.5

Załączam ostatni raport. Nie było większych aktualizacji w ciągu ostatnich kilku dni. Cały raport wraz z odnośnikami do dyskusji możecie znaleźć pod adresem:

http://members.cox.net/tmolina/kernprobs/status.html

Uwagi:

Stan podsytemu IDE w 2.5 jest na tyle zmienny, że śledzenie problemów w nim nie jest zbyt owocne. Nie będę raczej dodawał nowych przez zamrożeniem, o ile nie będzie specjalnego żądania. Obsługa dyskietek w 2.5 jest zepsuta. Rzeczy z wyższym priorytetem opóźniają prace nad poprawką.

Raport z problemami w jądrze 2.5 na 16 sierpnia

Nazwa problemu                    Stan         Dyskusja
problem z RAID 0 BIO              otwarty      2.5.30
schedule() z wyłączonymi
przerwaniami!                     otwarty      2.5.30
błędy w sterowniku bonding w 2.5  zamknięty    2.5.30
oops w obsłudze portu szeregowego zamknięty    2.5.30
obejścia dla NUMA-Q               zamknięty    2.5.30
problem z PnP BIOS                zamknięty    2.5.30 
nowe połączenia zamierają         zamknięty    2.5.30
oops w JFS                        zamknięty    2.5.30
obsługa portu szeregowego na
osadzonym PPC                     zamknięty    2.5.30 
oops w handle_scancode            zamknięty    2.5.30
zakleszczenie spinlocków          zamknięty    2.5.30
problem w smp                     zamknięty    2.5.30
process_stress z LTP powoduje
oopsa                             otwarty      2.5.30
oops w elv_queue_empty            otwarty      2.5.30
oops przy zapisie stron           otwarty      2.5.30
BUG w slab                        otwarty      2.5.30
problem z pmd_page                otwarty      2.5.30
problem z konsolą vga             otwarty      2.5.30
problem z uruchamianiem P200MMX   otwarty      2.5.30
prolem z io apic                  otwarty      2.5.30
oops w dcache                     otwarty      2.5.30
oops w vm86                       otwarty      2.5.30
nie działają moduły               otwarty      12 sie 2002
oops w unmount                    otwarty      12 sie 2002
problem z usb                     otwarty      11 sie 2002
nie działają moduły               otwarty      13 sie 2002
BUG w pte.chain                   otwarty      13 sie 2002
oops w scancode                   otwarty      12 sie 2002
zepsute cciss                     zaproponowana poprawka 14 sie 2002
oops w qlogicisp                  otwarty      14 sie 2002
oops w kmap_atomic                otwarty      15 sie 2002

gcml2 jest (oprócz kilku innych rzeczy) weryfikatorem składni linuksowego języka kconfig. Wersja 0.7 jest dostępna pod adresem:

http://sourceforge.net/project/showfiles.php?group_id=18813&release_id=106023

oraz

http://www.alphalink.com.au/~gnb/gcml2/download.html

Dostępny jest również zbiór ostrzeżeń i błędów analizatora składni, razem z prawdziwymi przykładami - do pobrania z:

http://www.alphalink.com.au/~gnb/gcml2/checker.html

Oto lista zmian:

• Konkretne ostrzeżenia mogą być osobno włączane. Domyślne ustawienia zależą od tego, czy weryfikator pracuje w trybie scalania. Funkcje API do włączania/wyłączania ostrzeżeń wg indeksu oraz konwersji nazw do formatu indeksowania.
• Dodana weryfikacja dla definicji nieliteralnych wyrażeń.
• Bardziej precyzyjna weryfikacja wieloznacznych porównań dla ,,n'', która nie ,,skarży'' się na ,,wyprzedzające'' deklaracje w danym miejscu, przy porównaniu.
• Przekształcenie ostrzeżeń o niespójnych znacznikach do bardziej precyzyjnej postaci; nie tworzą już zaskakujących ostrzeżeń o define_bool nie posiadających znacznika (EXPERIMENTAL).
• Dokładniejsza analiza dla przyszłych odniesień i zależności może uwidocznić różnicę pomiędzy przyszłymi a niezadeklarowanymi, kosztem zajmowanego miejsca.
• Weryfikacja zachodzących na siebie definicji poprzez redukcję warunków do postaci normalnej rozłącznej.
• Dodana weryfikacja przyszłych zależności.
• Dodano weryfikację dla błędnego użycia oraz zależności dla stałych, względem danej architektury, symboli -- takich jak CONFIG_X86.
• Zmiana nazwy summarise-warnings.awk -> summarize.awk i zainstalowanie tego.
• Dodano skrypt cml-summarize, który uruchamia summarize.awk.
• Dodano skrypt powłoki cml-check-all, bazujący na dochecks.sh, który teraz obsługuje także wywoływanie cml-summarize.
• Dodano strony manuala dla cml-check, cml-check-all oraz dla cml-summarize. Opis błędów i ostrzeżeń dla stron manuala cml-check jest kontrolowany w HTML i współdzielony ze stroną web.
• Obsługa pakietów RPM: dodano plik spec oraz rpm: jako cel kompilacji.

ta łatka jest kolejnym krokiem w drodze do osiągnięcia wyśmienitej obsługi wątków zaimplementowanej pod Linuksem.

każde istniejące jądro Linuksa, włączając w to 2.5.31, ma z natury nieskalowalną implementację sys_exit(), posiadającą narzut, który rośnie wraz ze wzrostem liczby zadań w systemie. Nie ma znaczenia to, czy te zadania wykonują jakąś pracę - uśpione zadanie też powoduje, że narzut na sys_exit() rośnie.

200 zadań w systemie jest typowe dla względnie jałowego systemu. 1000 zadań albo więcej nie jest takie rzadkie na średnich serwerach. Są serwery, które używają 5000 zadań albo więcej. Nierzadko, przy bardzo wątkowanym kodzie, używane jest jeszcze więcej wątków - modele klient-serwer często najłatwiej zaimplementować przy użyciu modelu z jednym wątkiem na pojedyncze połączenie. [Na przykład vsftpd, jeden z najszybszych i najbezpieczniejszych serwerów pod Linuksa używa dwóch (często trzech) wątków na każde połączenie klienckie [co, z powodu bezpieczeństwa, jest zaimplementowane przez wewnętrzne, odizolowane procesy klientów].]

Parę liczb, żeby to potwierdzić, testowałem 2.5.31-BK-curr na PIII 525 MHz, uzyskałem następujące opóźnienia fork+exit w lat_proc:

  liczba zadań w systemie            200   1000    2000    4000
  ------------------------------------------------------------------
  ./lat_proc fork+exit (mikrosekundy):  743.0  923.1  1153.4  1622.2

można zauważyć, że narzut na fork()+exit() podwaja się, a nawet więcej przy każdych dodatkowych 4000 zadań w systemie.

dla aplikacji z wątkami sytuacja wygląda nawet gorzej. Wątkowy test porównawczy, który testuje po prostu (liniowe) tworzenie i zakończenie 100 tysięcy wątków przy użyciu starej biblioteki glibc libpthreads, daje następujące wyniki:

  liczba zadań w systemie                200   1000    2000    4000
  ------------------------------------------------------------------
  ./perf -s 100000 -t 1 -r 0 -T
  w sekundach:	                             17.8   37.3    61.1   108.0

  opóźnienie jednowątkowego create+exit
  w mikrosekundach:                           178    373     611    1080

przy użyciu tego samego testu skonsolidowanego z nową libpthreads:

  liczba zadań w systemie                200   1000    2000    4000
  ------------------------------------------------------------------
  ./perf -s 100000 -t 1 -r 0 -T
  w sekundach:                                6.8   25.6    48.7    95.1

  opóźnienie jednowątkowego create+exit
  w mikrosekundach:                            68    256     487     951

występuje taka sama regresja, co w przypadku starego pthreads, ale przy (dramatycznie) niższej podstawie [którą zawdzięczamy innym optymalizacjom]. Przy stworzonej setce wątków, opóźnienia create+exit zaczynają dominować nad wielkim narzutem generowanym przez sys_exit().

wszystko w jednym - sys_exit() jest O(nr_tasks), i ponieważ tak jest, to nawet rozsądna liczba zupełnie jałowych zadań bardzo widocznie podnosi narzut na exit().

dlaczego sys_exit() jest takie kosztowne? Główny narzut znajduje się w forget_original_parent(), które musi być wołane dla każdego kończącego się wątku: jądro musi znaleźć wszystkie dzieci kończącego się zadania, które to zadanie utworzyło w trakcie swojego istnienia i musi zmienić im rodzica na jakieś inne zadanie. Obecna implementacja używa for_each_task() dla wszystkich zadań w systemie i znajduje takie, których prawdziwym rodzicem jest kończące się właśnie zadanie. To jest podstawa jądra, która nie może zostać zoptymalizowana - drzewo rodzice-dzieci musi zawsze pozostawać spójne.

ale iteracja for_each_task() jest nadmiarowa. Jest jednak subtelny powód by to stosować: ptrace zmienia rodzica debugowanego zadania na zadanie debugujące, które odłącza dziecko od pierwotnego rodzica. Stąd forget_original_parent() musi przeszukać całą listę zadań, aby upewnić się, że nawet debugowanym zadaniom właściwie zmieniono rodzica.

załączona łata (na BK-curr) zmienia implementację tego pomysłu w sposób skalowalny: kod pthreads utrzymuje także globalną listę debugowanych zadań, która zwykle, w normalnym systemie, jest pusta. Jest na niej najwyżej kilka zadań - te, które są obecnie debugowane. Posiadanie takiej listy w kilku strategicznych miejscach nie jest zbyt kosztowne.

forget_original_parent() przeszukuje wtedy listę dzieci kończącego się zadania oraz globalną listę ptrace. W zwykłym przypadku zadania, które nie ma dzieci i żadne zadania nie są debugowane, takie przeszukiwanie kosztuje tyle, co dwa sprawdzenia list_empty()!

czas przejść do wyników testów wydajnościowych na tej samej maszynce z PIII 525 MHz, lat_proc:

  liczba zadań w systemie                200     1000     2000     4000
  ----------------------------------------------------------------------
  ./lat_proc fork+exit (mikrosekundy):
                                      	    657.1    680.6    640.8    682.5

  (wyniki przy niezałatanym jądrze):       (743.0)  (923.1) (1153.4) (1622.2)

opóźnienie wynikające z tworzenia procesu jest ogólnie stałe, jest niezależne od liczby zadań w systemie. Nawet podstawowe wyniki zostają poprawione o więcej niż 10%. Dla 4000 zadań przyspieszenie wynosi więcej niż 130%.

przyspieszenie jest nawet większe dla aplikacji z wątkami, używających starego kodu pthreads:

  liczba zadań w systemie            200    1000    2000    4000
  --------------------------------------------------------------------
  ./perf -s 100000 -t 1 -r 0 -T
  w sekundach:                           12.6    12.8    11.9    11.9
  (wyniki bez łaty):                    (17.8)  (37.3)  (61.1) (108.0)

  opóźnienie jednowątkowego create+exit
  w mikrosekundach:                       126    128     119      119
  (niezałatane jądro):                   (178)   (373)   (611)  (1080)

  poprawa:                                 41%    191%   413%     807%

to znaczy, że w przypadku 4000 zadań poprawa jest prawie dziesięciokrotna!

testowanie libpthreads w nowej glibc pokazuje dramatyczną poprawę:

  liczba zadań w systemie                200   1000    2000    4000
  ------------------------------------------------------------------
  ./perf -s 100000 -t 1 -r 0 -T
  w sekundach:                             1.7    1.9     1.9     1.9
  (wyniki bez łaty):                      (6.8) (25.6)  (48.7)  (95.1)

  opóźnienie jednowątkowego create+exit
  w mikrosekundach:                         17     19      19      19
  (niezałatane jądro):                     (68)  (256)   (487)   (951)


  poprawa:                                 300%  1247%   2463%   4900%

W przypadku 200 zadań przyspieszenie jest czterokrotne, przy 4000 zadań, jest ono pięćdziesięciokrotne (!). Opóźnienie przy tworzeniu i usuwaniu wątku to stale 19 mikrosekund. Umożliwia to również bezpośrednie porównania starego pthreads i nowego libpthreads: nowe libpthreads jest więcej niż 6 razy szybsze. To jest to, co w końcu mógłbym nazwać dobrą wydajnością wątków.

najtrudniejszą częścią łatki było zapewnienie poprawności semantyki ptrace. Sądze, że zdołałem to przetestować przynajmniej przy typowych obciążeniach: testowałem złożone mieszanki sytuacji strace przy dużych obciążeniach, dla wątkowego i niewątkowego kodu, dla SMP i UP, zatem jestem w miarę pewien, że to działa dla takich rodzajów obciążeń, jakie występują na moich systemach [ Ale ptrace() jest tak niewiarygodnie złożone, że mogłem równie dobrze opuścić niektóre subtelne przypadki. ]

• łatka zawiera również inną optymalizację, ułatwiającą także wykonanie bash-owego wait4(): wait4() nie musi zajmować się niedebugowanymi zadaniami CLONE_DETACHED, nie dostanie od nich żadnego kodu powrotu, a te zadania same po sobie sprzątają.
• łatka porządkuje także <linux/ptrace.h> i przenosi deklaracje specyficzne dla pthread z mm.h do ptrace.h - większość istniejących włączeń była zbędna.

Hmm.. Wygląda dobrze, ale zastanawiam się, czy prawdziwy problem nie leży w tym, że nasze podejście do ptrace zawsze było trochę nadęte.

Zaczęliśmy od założenia, że tylko rodzice mogą śledzić swoje dzieci, zatem nigdy nie potrzeba było zmiany rodziców. Potem nadeszło PTRACE_ATTACH i zrobiliśmy zmianę rodzica. Sądzę, że właśnie w _tym_ miejscu popełniliśmy wielki błąd.

Powinniśmy mieć oddzielny wskaźnik ,,tsk->tracer'' zamiast używać perwersyjnego podejścia, w którym ,,mój rodzic mnie śledzi''. Nie powinniśmy naprawdę zmieniać relacji między rodzicem a dzieckiem tylko dlatego, że wątek jest śledzony.

Z przyjemnością zastosuję tę łatkę (znaczy poprawioną wersję), ale sądzę, że wolałbym zrobić więcej, to znaczy usunąć całą zmianę rodzica i trzymać listę wszystkich dzieci przez cały czas trwania procesu. Jak bolesne by to było?

Ta łatka dodaje obsługę kontrolera IDE vt8235 w jądrze 2.4. Jest bardzo potrzebna, bo ten układ właśnie wchodzi do sklepów.

Taka sama łatka powinna wkrótce wejść do 2.5.

Możecie zaimportować zbiór zmian do BK przez przekierowanie tej wiadomości do: '| bk receive [ścieżka do repozytorium]', bądź zwyczajnie aplikując łatkę.

Ten dokument jest wysyłany na listę regularnie i będzie modyfikowany zawsze, gdy nowa ofiara zażyczy sobie umieszczenia na tej liście, albo gdy ktoś nie będzie mógł dłużej poświęcać swojego czasu na pracę opiekuna.

Jeśli chcesz, by notka o Tobie została dodana/uaktualniona/usunięta, to skontaktuj się ze mną.

------- tu odetnij ------ tu odetnij ------ tu odetnij ------ tu odetnij ------

Jeśli jesteś nowy wśród hakerów jądra Linuksa i chcesz przesłać raport o błędzie w jądrze, albo łatkę, ale nie wiesz jak to zrobić, ani _gdzie_ to zgłosić?

Przygotowanie raportu o błędzie:

Problemy z kompilacją: zgłoś to, co na wyjściu daje GCC, oraz wynik polecenia ,,grep '^CONFIG_' .config''
Oops: zdedkoduj go przy pomocy ksymoops
Proces nie do zabicia: Alt-SysRq-T i ksymoops na odpowiedniej części.
Tak. To znaczy, że powinieneś mieć zainstalowane i przetestowane ksymoops, co łatwo zrobić źle. Zbyt często tak robiłem.

Więcej informacji w FAQ dostępnym na http://www.tux.org/lkml/

Przesyłanie raportu o błędzie/łatki:

• Sterowniki niektórych urządzeń mają aktywnych deweloperów, spróbuj najpierw skontaktować się z nimi.
• Jeśli się nie uda, to znajdź opiekuna podsystemu, którego dotyczy raport i wyślij go na jego adres.
• Małe poprawki i uaktualnienia sterowników urządzeń najlepiej kierować do opiekunów podsystmeów i do integratorów ,,małych kawałków''
• Wpisanie Linux kernel mailing list w CC: listu nie boli, ale jeśli w To: nie wpiszesz adresu konkretnego opiekuna, to z wysokim prawdopodobieństwem twoja łata nie zostanie zauważona. Zostałeś ostrzeżony.
• Nie wysłaj tego na raz na wszystkie adresy. To wkurzy wiele osób i w ogóle nie jest użyteczne. To spam.
• NIE podsyłaj małych poprawek Linusowi, on po prostu nie ma szans obsłużyć _wszystkiego_. W końcu dostanie to od opiekunów/integratorów, przesyłaj to co masz przez nich.
• Jeśli twoja łatka jest czymś dużym i nowym, to ogłoś ją na lkml i spróbuj przyciągnąć testerów. Po tym jak zostanie przetestowana i przedyskutowana, możesz oczekiwać, że Linus rozważy jej włączenie do głównego jądra.

Obecni ludzie jądra

Zauważcie, że ta lista jest posortowana datami, w odwrotnej kolejności, to znaczy najpierw podaję najnowsze pozycje listy. Oznacza to, że pozycje na samym jej dole mogą być już nieważne :-(

Linux kernel mailing list <linux-kernel@vger.kernel.org>
        Wysyłaj tu wszystko związane z jądrem Linuksa, ale nic poza tym :-)

Dave Engebretsen <engebret@vnet.ibm.com> [15 aug 2002]
        Opiekun architektury PPC64. Proszę przesyłać łaty na PPC64 do mnie i na naszą
        listę, na adres <linuxppc64-dev@lists.linuxppc.org>

Ingo Molnar <mingo@elte.hu> [30 lip 2002]
        Ingo napisał nowy algorytm szeregujący dla 2.5.

Ralf Baechle <ralf@uni-koblenz.de> [30 lip 2002]
        Jestem opiekunem kodu AX.25

Victor Yodaiken <yodaiken@fsmlabs.com> [30 lip 2002]
        łatki, uaktualnienia, dodatki, sterowniki RTLinux.
        Pisz najpierw na listę: rtl@rtlinux.org

Pavel Machek <pavel@ucw.cz> [27 lip 2002]
        Jestem opiekunem sieciowych urządzeń blokowych.
        Odwiedź: http://nbd.sf.net.
        (patrz: Steven Whitehouse <steve@gw.chygwyn.com> na tej liście)
        Pracuję nad programowym zawieszaniem.

William Irwin <wli@holomorphy.com> [02 lip 2002]
        Wysyłaj do mnie raporty błędów i/lub prośby o nowe cechy związane z wieloma
        zadaniami, rmap, zużycie przestrzeni, alokacje. Jestem zaangażowany w:
        * rmap
        * alokację pamięci
        * redukcję przestrzeni zużywanej przez struktury danych (np. struct page)
        * problemy pojawiających się przy dużych obciążeniach, w związku z różnymi zadaniami
        * nadzorowanie kodu jądra
        Patrz także:
        Rik van Riel <riel@surriel.com>
        Andrea Arcangeli <andrea@suse.de>
        Martin Bligh <Martin.Bligh@us.ibm.com>
        Andrew Morton <akpm@zip.com.au>

Dave Jones <davej@suse.de> [23 kwi 2002]
        Zbieram różne kawałki i fragmenty kodu do włączenia w 2.5,
        szczególnie te małe i trywialne oraz uaktualnienia sterowników.
        Przekażę je Linusowi gdy (i jeśli) zostanie udowodnione, że są tego
        warte.

Andre Hedrick <andre@linux-ide.org> [09 kwi 2002]
        Architekt ATA/ATAPI Storage  [2.0,2.2,2.4]
        Deweloper interfejsu HBA
        Architekt szeregowego ATA [w przyszłych wersjach]
        Członek NCITS komitetu AT-Attachment z prawem głosu

Andrea Arcangeli <andrea@suse.de> [28 mar 2002]
        Przysyłajcie mi raporty błędów i łaty dotyczące VM.
        W szczególności interesują mnie następujące problemy z VM:
        * dużo RAMu i procesorów
        * NUMA
        * scenariusze z dużym udziałem partycji wymiany
        * wydajność przy dużych obciążeniach WE/WY (szególnie, gdy odbywa się
          dużo asynchronicznego czyszczenia buforów)
        Patrz także: Martin J. Bligh <Martin.Bligh@us.ibm.com>
        Piszcie także do:
        Arjan van de Ven <arjanv@redhat.com>

Martin J. Bligh <Martin.Bligh@us.ibm.com> [28 mar 2002]
        Jestem zainteresowany kwestiami związanymi z VM przy dużej
        (>4G przy i386) ilości RAM, wieloma procesorami, NUMA

Steven Whitehouse <steve@chygwyn.com> [27 mar 2002]
        Jestem opiekunem stosu sieciowego DECnet w Linuksie
        Odwiedź http://www.chygwyn.com/decnet/

Arnaldo Carvalho de Melo <acme@conectiva.com.br> [26 mar 2002]
        IPX, 802.2 LLC, NetBEUI, http://kerneljanitors.org,
        sterownik karty cyclom2x sync

John Cagle <jcagle@kernel.org> [19 mar 2002]
        Obecny opiekun devices.txt, listy przypisanych numerów urządzeń dla
        LANANA. Przeczytaj stronę w sieci (www.lanana.org) w celu uzyskania
        instrukcji jak przesyłać prośby o nowe numery urządzeń. Prześlij wszystkie
        prośby związane z urządzeniami na adres:
        <device@lanana.org>.

Tigran Aivazian <tigran@veritas.com>
        Jestem autorem i opiekunem systemu plików BFS i sterownika aktualizacji
        mikrokodu dla IA32

Rogier Wolff <R.E.Wolff@BitWizard.nl> [12 mar 2002]
        Robię ,,porty szeregowe specialix'':
        drivers/char/specialix.c (IO8+)
        drivers/char/sx.c        (SX, SI, SIO)
        drivers/char/rio/*.c     (RIO)

Martin Dalecki <martin@dalecki.de> [11 mar 2002]
        opiekun podsystemu IDE w 2.5
        (piszcie też do Vojtecha Pavlika <vojtech@suse.cz>)

Ed Vance <serial24@macrolink.com> [05 mar 2002]
        Opiekun podstawowego sterownika szeregowego, serial.c, dla
        jąder 2.2 i 2.4. Proszę, przesyłajcie łatki na adres
        linux-serial@vger.kernel.org z przetestowanymi poprawkami błędów
        albo żeby dodać obsługę nowych urządzeń szeregowych.
        Ograniczenia dostępnego czasu. Jeśli nie odpowiadam w ciągu
        tygodnia, wrzeszczcie na serial24@macrolink.com

deweloperzy netfilter/iptables <netfilter-devel@lists.samba.org> [23 feb 2002]
        Na tę listę, na której są deweloperzy netfilter, proszę zgłaszać
        wszystkie problemy związane z netfilter/iptables.
        Patrz także: http://www.netfilter.org/contact.html

Hans Reiser <reiser@namesys.com> [16 lut 2002]
        Przesyłajcie mi wszystkie łatki dotyczące reiserfs z
        cc: do reiserfs-dev@namesys.com, a raporty błędów na
        reiserfs-dev@namesys.com, żądania opłaconej obsługi przesyłajcie
        na support@namesys.com po zapłaceniu na
        www.namesys.com/support.html,
        wszelkie dyskusje (nie raporty błędów, no chyba, że zainteresują większość
        osób) ślijcie na reiserfs-list@namesys.com.
        Jeśli przez tydzień nie odpowiemy na twoją łatę, krzycz na nas, zasłużliśmy.
        Aby dowiedzieć się więcej o przesyłaniu nam łatek, pracy z nami i naszym
        systemie przesyłania i śledzenia łatek obejrzyj naszą stronę na www.namesys.com.

Paul Bristow <paul@paulbristow.net> [16 lut 2002]
        Jestem opiekunem sterownika stacji dyskietek na ide
        (ATAPI ZIP, LS-120/240 Superdisk, napędy Clik!).

Mike Phillips <phillim2@comcast.net> [15 lut 2002]
        Podystem Token ring i sterowniki.

Anton Altaparmakov <aia21@cam.ac.uk> [15 lut 2002]
        Jestem gościem od NTFS.

https://bugzilla.redhat.com/bugzilla [14 lut 2002]
        Zgłaszanie problemów z jądrami dostarczanymi przez Red Hat.

Alan Cox <alan@lxorguk.ukuu.org.uk> [14 lut 2002]
        Opiekun Linuksa 2.2 (tylko poprawki konserwujące).
        Utrzymuję zestawy łatek na nieutrzymywane rzeczy w 2.2/2.4.
        Opiekun drzewa 2.4-ac (2.4 z testowanymi rzeczami).
        I2O, dźwięk, opiekun 3c501 w 2.2/2.4.

Robert Love <rml@tech9.net> [14 lut 2002]
        Wywłaszczalne jądro jest moje.

Deweloperzy ALSA <alsa-devel@alsa-project.org> [12 lut 2002]
Jaroslav Kysela <perex@perex.cz> [12 lut 2002]
        Advanced Linux Sound Architecture
        Łatki ALSA są dostępne pod adresem:
        ftp://ftp.alsa-project.org/pub/kernel-patches/*

Neil Brown <neilb@cse.unsw.edu.au> [08 feb 2002]
        Jestem zainteresowany wszystkimi kwestiami, które dotyczą następującego kodu:
        serwer NFS        (fs/nfsd/*)
        programowego RAID (drivers/md/{md,raid,linear})
        lub innych związanych z tym plików

Maksim Krasnyanskiy <maxk@qualcomm.com> [08 lut 2002]
        Jestem autorem i opiekunem podystemu Bluetooth i sterownika urządzenia
        Universal TUN/TAP.
        Obecnie pracuję głównie nad rzeczami związanymi z Bluetooth.

Rik van Riel <riel@conectiva.com.br> [07 lut 2002]
        Przysyłajcie mi rzeczy związane z VM, z CC: do linux-mm@kvack.org, proszę.

Geert Uytterhoeven <geert@linux-m68k.org> [07 lut 2002]
        Pracuję nad podystemem bufora ramki, przeniesieniem na m68k (część dotycząca
        Amigi) i przeniesieniem na PPC (część CHRP LongTrail).
        Niestety, nie mam zbyt wiele wolnego czasu by naprawdę popracować nad tymi
        rzeczami. Moja praca zawodowa nie jest związana z Linuksem (na razie :-). Nie
        mogę nic obiecać w kwestii mojej wydajności jako opiekuna.

H. Peter Anvin <hpa@zytor.com> [07 lut 2002]
        kod uruchamiania dla i386
        protokół startowania dla i386, autofs3,
        skompresowane iso9660
        (ale przyjmę wszystkie zmiany związane z iso9660);
        kierownik stron kernel.org; proszę się ze mną kontaktować
        w sprawach związanych ze sponsorowaniem.

administratorzy kernel.org <ftpadmin@kernel.org> [07 lut 2002]
        Administratorzy kernel.org. Daj nam znać jeśli coś nie działa, a jeśli
        chcesz jakiejś zmiany, to upewnij się, że dajesz nam przynajmniej 1-2 tygodnie.
        Zwróć uwagę proszę, że dostajemy dużo próśb o nowości, a dużo z nich
        nie daje się pogodzić, albo po prostu nie są praktyczne; nie mamy czasu, by
        odpowiadać na wszystkie prośby.

Greg KH <greg@kroah.com> [07 lut 2002]
        Jestem opiekunem USB i PCI Hotplug.

Trond Myklebust <trond.myklebust@fys.uio.no> [07 lut 2002]
        Jestem opiekunem klienta NFS.

James Simmons <jsimmons@transvirtual.com> [07 lut 2002]
        Podsystemy konsoli i bufora ramki.
        Bawię się także warstwą wejścia. 

Richard Gooch <rgooch@atnf.csiro.au> [07 lut 2002]
        Opiekuję się devfs. Chciałbym żeby ludzie umieszczali mnie w Cc:, gdy zgłaszają
        problemy z devfs, ponieważ nie czytam wszystkich informacji na linux-kernel.
        Przesyłajcie łatki na devfs bezpośrednio do mnie, nie pomijajcie mnie
        wysyłając je Linusowi/Marcelo/Alanowi/Dave'owi itp.

Russell King <rmk@arm.linux.org.uk> [06 lut 2002]
        Opikeun architektury ARM. Proszę, przesyłajcie mi wszystkie łatki na ARM przez system
        łatek dostępny pod adresem:
        http://www.arm.linux.org.uk/developer/patches/
        Opiekun nowych sterowników portu szeregowego w 2.5. Przesyłaj łatki na
        rmk+serial@arm.linux.org.uk

Andrew Morton <akpm@zip.com.au> [05 lut 2002]
        Jestem wrażliwy na każdy reprodukowalny błąd w którymkolwiek miejscu jądra 2.4.
        Specjalizuję się w ext2, ext3 i sterownikach sieciowych.
        Nie myślę o 2.5.x w tej chwili.

Petr Vandrovec <vandrove@vc.cvut.cz> [05 lut 2002]
        system plików ncpfs, sterownik bufora ramki dla matrox,
        problemy związane z VMware - w 2.2.x, 2.4.x, jak i 2.5.x.

Lista deweloperów reiserfs <reiserfs-dev@namesys.com> [05 lut 2002]
        Wysyłaj wszystkie rzeczy związane z reiserfs włączając w to raporty, poprawki,
        propozycje, ale też wszystkie inne rzeczy.

Oleg Drokin <green@linuxhacker.ru> [05 lut 2002]
        SA11x0 USB-ethernet i SA11x0 watchdog są moje.

Vojtech Pavlik <vojtech@ucw.cz> [05 lut 2002]
        Nie wahaj się wysłać mi raportu o błędach i łatek na sterowniki urządzeń wejściowych
        (drivers/input/*, drivers/char/joystick/*)
        Chciałbym także dostawać raporty o błędach i łatki dla następujących sterowników USB:
        printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
        Wszystkie inne (spoza listy) zmiany sterowników USB powinny iść do
        opiekuna USB (mam nadzieję, że jest jakiś na tej liście :-).
        Umieść mnie w CC jeśli wysyłasz informacje związane ze sterownikiem VIA IDE
        (jakkolwiek nie jestem opiekunem podystemu IDE).

======= Te pozycje zaproponowali ludzie na lkml ========

Ralf Baechle <ralf@gnu.org> [27 mar 2002]
        Jestem opiekunem mips/mips64.

David S. Miller <davem@redhat.com> [07 lut 2002]
        Jestem opiekunem Sparc64 i podstaw obsługi sieci.

======= Te napisałem sam ========
======= Czekam na potwierdzenie/poprawki od tych ludzi ========

Urban Widmark <urban@teststation.com> [13 lut 2002]
        smbfs

Jeff Garzik <jgarzik@mandrakesoft.com> [12 lut 2002]
        Jestem gościem od sterowników kart sieciowych (8139 na przykład).
        Umieść mnie i Andrew Mortona <akpm@zip.com.au> w CC: listów dotyczących
        łat na sterownik sieci.

Lista dyskusyjna video4linux <video4linux-list@redhat.com> [12 lut 2002]
Gerd Knorr <kraxel@bytesex.org> [12 lut 2002]
        video4linux

Tim Waugh <twaugh@redhat.com> [08 lut 2002]
        > Kto opiekuje się rzeczami związanymi z linux iomega?
        W 2.4.x, ja (teoretycznie). W tej chwili nie mam czasu na 2.5.x.

Alexander Viro <viro@math.psu.edu> [5 lut 2002]
        NIE jestem opiekunem podsystemu systemów plików. Ale nie zabiję cię, jeśli
        przyślesz mi jakieś raporty błędów generalnie dotyczące fs i (mam nadzieję) łatki.

Eric S. Raymond <esr@thyrsus.com> [5 lut 2002]
        Przesyłaj mi raporty błędów i propozycje dotyczące konfiguracji jądra.
        Będę też bardziej niż zadowolony, gdy dostanę pozycje ,,pomocy'' dla
        opcji konfiguracyjnych jądra (Configure.help)

G?rard Roudier <groudier@free.fr> [5 lut 2002]
        Jestem gościem od SCSI.

Jens Axboe <axboe@suse.de> [5 lut 2002]
        Jestem opiekunem podsystemu urządzeń blokowych.

Keith Owens <kaos@ocs.com.au> [5 lut 2002]
        ksymoops, kbuild, .. .. .. .. .  są moje.

Linus Torvalds <torvalds@transmeta.com> [5 lut 2002]
        Nie przysyłaj mi niczego, chyba, że jest to dla 2.5 i dobrze przetestowane,
        przedyskutowane na lkml i używane przez znaczącą liczbę ludzi.
        Przesyłanie mi małych poprawek i uaktualnień sterowników jest
        generalnie złym pomysłem; prześlij je opiekunom podystemów i/lub do integratorów
        ,,małych rzeczy'' (obecnie jest to Dave Jones <davej@suse.de>,
        zobacz pozycję na tej liście dotyczącą jego). Wybaczcie, nie mogę robić wszystkiego.

Marcelo Tosatti <marcelo@conectiva.com.br> [5 lut 2002]
        Nie przysyłaj mi niczego, chyba, że jest to dla 2.4 i dobrze przetestowane.
        Jeśli przysyłasz małe poprawki albo aktualizacje sterowników, prześlij kopię
        do opiekuna podystemu i/lub do integratorów ,,małych rzeczy'':
        - Alan Cox <alan@lxorguk.ukuu.org.uk>,
        - Rusty Russell <trivial@rustcorp.com.au>.

Rusty Russell <rusty@rustcorp.com.au> [5 lut 2002]
        > Oto pewne poprawki czyszczące kod w...
        Chcesz, żeby to dodał do zestawu trywialnych łatek, żeby zostało prześledzone?
        Jeśli tak, to pisz (lub wstaw adres w cc:) na trivial@rustcorp.com.au.