Kernel Traffic #122 For 18 Jun 2001

There were 393 different contributors. 190 posted more than once. 152 posted last week too.

Derek Glidden pokazał, w jaki sposób może spowodować stan, w którym jego maszyna przestaje odpowiadać na jakiekolwiek bodźce przez kilka minut. Przypisał to zachowanie obsłudze VM w 2.4 i dodał, że uważa iż zostało jeszcze parę poważnych problemów w obsłudze VM zanim ta będzie mogło zostać uznana za stabilną. Inni potwierdzili to zachowanie i rozpoczęła się dłuższa dyskusja. W pewnym momencie Miles Lane powiedział: "Mike i inni, mam już dość Waszych komentarzy. Grgh. Różne osoby, które doskonale znają te problemy, cały czas nad tym pracują i wypróbowują kolejne poprawki, włączając w to ostatni zaaplikowany patch. Wydaje się oczywiste, że problemy różnych ludzi z nowym sposobem traktowania swapa przez VM zostały zauważone i trwają teraz prace nad poprawkami. Być może nie zostanie to naprawione jutro, ale niedługo. Czego jeszcze kurde chcecie?" Derek odpowiedział, że jego pierwotny list miał za zadanie dać użyteczne dane, i Miles zgodził się: "Rzeczywiście. Sądzę, że Twoja wiadomość była użyteczna. Spowodowała zmianę paru założeñ odnośnie architektury VM w 2.4 i pomogła znaleźć kilka błędów. To nie o Tobie pisałem w poprzednim mailu. To nie Ty wysyłałeś bezcelowe uwagi odnośnie wymagañ dyskowych na ilość swapu w jądrach 2.4, nie dając żadnych użytecznych informacji dla developerów. Tak więc, dziękuję za zainicjowanie dyskusji :-)"

Być może masz rację, ale to co tak naprawdę pokazałeś to to, że implementacja ,,swapoff()'' jest wybitnie (mam na myśli _WYBITNIE_) nieefektywna. Nie wynika z tego jednak, że obsługę VM można uznać za niestabilną i niedziałającą. Sytuacja w 2.4.x pogorszyła się nie tyle ze względu na zmiany we właściwym kodzie VM, co ze względu na fakt, że bardziej rzadsze opróżnianie swapa w 2.4.x, jest bardziej podatne na niską wydajność ,,swapoff()''. Nie przypuszczam żeby sam algorytm swapoff() się zmienił. Wydaje mi się, że po prostu ten algorytm działa w czasie wykładniczym (i z powodu stałej zawartości cache w swapie, ,,n'' w algorytmie szybko rośnie). To jest zupełnie inny problem niż równoważenie pamięci wirtualnej. Popatrz jak wygląda kod ,,try_to_unuse()'' i spróbuj coś z tym zrobić. Bardzo bym się cieszył, gdyby ktoś popatrzył trochę więcej na swap-off. Być może swap-off nie oznacza poprawnie martwych stron w swapie - ktoś mógłby sprawdzić czy nie ma prób wczytania i wykonania ,,try_to_unuse()'' na martwych stronach w swapie. To mogłoby zwiększyć wydajność w sposób naprawdę znaczący.

Felix von Leitner zgłosił fakt, że niektóre nagłówki jądra mogę spowodować problemy z bibliotekami z userlandu, takimi jest dietlibc, zależnymi od nich, z powodu nieprawidłowego API. Pokazał prostą poprawkę, ale David S. Miller odpowiedział: "Nie używaj nagłówków jądra w przestrzeni użytkownika. Nagłówki jądra i nagłówki użytkownika używają różnych przestrzeni nazw, a Ty wymieniłeś jeden z wielu punktów, w których te przestrzenie się nie zgadzają i używamy innych nazw/struktur/etc niż aplikacje tego wymagają." Felix von Leitner lekko się zirytował: "A jaki mam wybór? Zdublować wszystkie nagłówki i potem mieć problem gdy zmieni się specyfikacja?" Linus Torvalds odparł:

Tak.

Jeszcze lepiej byłoby gdybyś zrobił tak: napisz nagłówki do przestrzeni użytkownika, które mają _tylko_ minimalną zawartość kodu. Nagłówki jądra mają dużo śmieci, które są tylko dla niego przeznaczone, co znaczy, że jeśli kompilujesz programy z przestrzeni użytkownika, będą one wolniejsze niż powinny.

Podstawową kwestią jest to, że jądro _nie_ będzie podążać za regułami ,,przestrzeni nazw dnia'' - C89, C99, POSIX, BSD, SuS, GNU,... Nagłówki jądra nie są przeznaczone dla przestrzeni użytkownika i nie będą ich obowiązywały sztywne zasady przestrzeni nazw iluśtam standardów.

Tak naprawdę to nie ma zbyt wielu użytecznych rzeczy w nagłówkach jądra. Większość z nich (tak jak IPv6) jest już pokryta w innych miejscach.

Peter J. Bramm zrobił rpmy z obsługą ext3 i udostępnił je pod ftp://ftp.clusterfilesystem.com/pub/ext3. P.A.M. van Dam spytał, gdzie może znaleźć łatę z ext3 do jąder 2.4. Andrew Morton odpowiedział:

Wszystkie szczegóły znajdziesz pod http://www.uow.edu.au/~andrewm/linux/ext3/

Obecny stan można określić jako ,,dość stabilny''. Wydajność jest dobra. Niestety ext3 jest nieprzetestowany z LVM i RAID-em. Może powstać blokada jeśli masz duże obciążenie i używasz quoty.

W przeciwnym przypadku nie powinieneś mieć żadnych problemów.

Włączenie obsługi do drzewa -ac i rozwiązanie problemów z quotą jest następną pozycję do zrobienia na liście.

Dawson Engler napisał programik do wyszukiwania błędów w kodzie źródłowym. Dokładniej: "Możecie popatrzyć na ten program, jak na śledzenie, czy dane z niewiarygodnego źródła (np. z copy_from_user) może dotrzeć do jakiegoś zasobu wymagającego poprawnych danych (np. indeksu w tablicy). Głównym ograniczeniem w tej chwili jest mały zbiór zagrożonych zasobów. Jeśli ktoś ma jakieś sugestie co do miejsc które mogą być podatne na na sprytne dane wejściowe od wstrętnych użytkowników, proszę o email z nimi." Do tego pokazał listę 15 błędów, które znalazł używając swojego ,,wyłapywacza''. Alan Cox szybko poprawił większość z nich, a Olivier Xymoron dodał:

Napisałem podobny programik dla przestrzeni użytkownika (działający przez ld preload). Skupiłem się głównie na śledzeniu napisów i sprawdzaniu czy jest sprawdzana ich długość aby zapobiec przepełnieniu stosu, ale sprawdzałem także argumenty dla open, itp.

W Twoim przypadku wszystkie w zasadzie wszystkie zasoby są zagrożone w jakimś stopniu: userspace daje Ci dane, żebyś je gdzieś umieścił. Zamiast badania przepływu danych przez funkcje, mógłbyś sprawdzić capabilities itp. Założę się, że zbadałbyś w ten sposób jakieś 90% kodu przy pomocy jedynie kilku sprawdzeñ.

Eric S. Raymond zgłosił odnalezienie kilku nowych symboli konfiguracyjnych w 2.4.6pre2, które nie mają odpowiedniej dokumentacji. Podał ich listę:

Maksim Krasnyanskiy dopraszał się elementów z CONFIG_BLUEZ, mówiąc, że należą one do podsystemu Bluetooth i dodając że Linux jest pierwszym systemem operacyjnym posiadającym oficjalne wsparcie dla Bluetooth. Opisał te opcje:

CONFIG_BLUEZ

Bluetooth jest tanią, zużywającym mało energii, krótkozakresową technologią bezprzewodową. Została zaprojektowana aby wymienić kable i inne krótkozakresowe technologie takie jak IrDa. Bluetooth działa w ustalonym zasięgu, który zwykle wynosi około 10 metrów. więcej informacji można znaleźć pod adresem http://www.bluetooth.com

Podystem Linux Bluetooth składa się z kilku warstw:

HCI Core (urządzenie i manager połączeñ, scheduler)
HCI Device drivers (interfejs do hardware)
L2CAP Module (protokół L2CAP)

Powiedz Y tutaj aby umożliwić wsparcie Linux Bluetooth i zbudować warstwę HCI Core.

Aby używać podsystemu Linux Bluetooth, będziesz potrzebować kilku narzędzi działających w trybie użytkownika, takich jak hciconfig i hcid. Te narzędzia i aktualizacje modułów jądra Bluetooth są dostarczane w pakiecie BlueZ. Więcej informacji pod adresem http://bluez.sf.net.

Jeśli chcesz skompilować HCI Core jako moduł (hci.o) odpowiedz tu M.

Brak niepewności ? powiedz N.

CONFIG_BLUEZ_L2CAP

L2CAP (Logical Link Control and Adaptation Protocol) dostarcza połączeniowe i bezpołączeniowe przesyłanie danych. Wsparcie dla L2CAP jest wymagane przez większość aplikacji Bluetooth.

Odpowiedz tu Y aby wkompilować wsparcie L2CAP w jądro albo odpowiedz M aby skompilować go jako moduł (l2cap.o).

Brak niepewności ? odpowiedz M.

CONFIG_BLUEZ_HCIUART

Sterownik Bluetooth HCI UART. Ten sterownik jest wymagany jeśli chcesz używać urządzeñ Bluetooth z interfejsem do portu szeregowego.

Odpowiedz tu Y aby wkompilować wsparcie dla urządzeñ Bluetooth UART w jądro albo odpowiedz M aby skompilować go jako moduł (hci_uart.o).

Brak niepewności ? odpowiedz M.

CONFIG_BLUEZ_HCIUSB

Sterownik Bluetooth HCI USB. Ten sterownik jest wymagany jeśli chcesz używać urządzeñ Bluetooth z interfejsem USB.

Odpowiedz tu Y aby wkompilować wsparcie dla urządzeñ Bluetooth USB w jądro albo odpowiedz M aby skompilować go jako moduł (hci_usb.o).

Brak niepewności ? odpowiedz M.

CONFIG_BLUEZ_HCIEMU

Sterownik urządzenia Bluetooth Virtual HCI. Ten sterownik jest wymagany jeśli chcesz używać oprogramowania emulującego HCI.

Odpowiedz tu Y aby wkompilować w jądro wsparcie dla urządzeñ Virtual HCI albo odpowiedz M aby skompilować je jako moduł (hci_usb.o).

Brak niepewności ? odpowiedz M.

Randy Dunlap zasugerował napisanie "Jesteś pewny? Odpowiedz M" ("Sure? say M")zamiast "Brak niepewności? Odpowiedz M" ("Not unsure? say M"), a Maksim zgodził się i wysłał poprawioną listą niedługo później.

Matt Nelson prowadzi projekt, który wymaga posiadania 6GM RAM-u na architekturze Intela i chciał wiedzieć, czy są jakieś zagwostki, o których powienien wiedzieć. Doug McNaught zasugerował użycie Alphy do tego celu i wyjaśnił: "Wskaźniki na IA32 są cały czas 32bitowe, więc (o ile dobrze rozumiem) każdy proces może zaadresować do 4GB RAM. Możesz zaadresować więcej (w pamięci dzielonej lub zmmap()owanych plikach) i mapować je do i z pamięci, gdy potrzebne." Dodał także: "jeśli rozdzielisz swoje zadanie na więcej procesów, tak aby żaden proces nie potrzebował więcej niż 4GB pamięci, IA32 będzie działać dobrze." Matt podziękował: "Dziękuję za wszystkie odpowiedzi. Nigdy nie potrzebowałem tyle pamięci, więc nie miałem pojęcia, w jaki sposób została zaimplementowana obsługa 64GB RAM na IA32. Niestety ta implementacja nie bardzo odpowiada moim potrzebom... cóż... będę musiał rozejrzeć się za niedrogą wieloprocesorowa Alphą..."

Craig Lyons z Promise Technology wysłał łatę do Andre Hedricka, wyjaśniając, "W jądrze 2.4 jest wsparcie dla niektórych naszych produktów (Ultra 66, Ultra 100, etc.). Nie wiem czy to wiadomo, ale nasza rodzina kontrolerów Ultra (w której są po prostu standardowe kontrolery IDE, które nie mają RAID) używa tego samego ASIC co nasze kontrolery FastTrak RAID. Jądro 2.4 rozpozna kontroler z rodziny Ultra, problem polega na tym, że FastTrak nie zostanie rozpoznany jako FastTrak, tylko jako Ultra. Zatem macierz FastTracków nie jest rozpoznawana jako macierz, zamiast tego każdy dysk jest widziany osobno i dane użytkowników nie mogą być w odpowiedni sposób uzyskiwane. Mamy łatę, która pomaga naprawić tę sytuację i zastanawiamy się czy jest możliwe włączenie tej łaty do jądra. " Andre odpowiedział, "Nie chcę i nie potrzebuję łat twojej firmy. Nie wezmę, nie zaakceptuję i nie pochwalę żadnego brudnego kodu, źle napisanego, binarnego sterownika, który nie kontroluje swojego ISR i który nieodpowiedzialnie koliduje z natywnym sterownikiem ATA."

Bert Hubert odpowiedział, "Craig skontaktował się z tobą żeby dowiedzieć się co było źle i powinieneś mu wytłumaczyć co było tak naprawdę problemem i jak mógłby go rozwiązać. Linus zaakceptowałby łaty napisane przez Billa Gatesa, jeśli tylko miałyby odpowiednią licencję i były dobrze napisane, nie wiem więc czemu Promise miało by być wyjątkiem. " Wyjaśnił także Craigowi, "Procedura wygląda tak, że łatę publikuje się najpierw dając ludziom możliwość jej wypróbowania i skomentowania. Często okazuje się, że taki kod nie jest taki jak trzeba, albo robi rzeczy, które nie podobają się ludziom od jądra. Nie ma w tym złych intencji, po prostu developerzy jądra są bandą wybrednych ludzi, którzy jednak, odpowiednio pogonieni, powiedzą ci co możesz zmienić w swoim kodzie by stał się on akceptowalny. Może się też zdarzyć, że ludzie mogą zobaczyć co powinno być zrobione w twojej łacie i mogą zrobić to sami." Ale Andre powiedział, "Nie, nie wziąłbym ich kodu i nie użył go. Chcę zachować stosowane i utrzymywane przez nas reguły API odnośnie sygnatur. Nie potrzebujemy ich sterownika." Rob Landlay zauważył, że Adre, jako maintainer, powinien być bardziej "otwarty" na ich łaty. Andre odpowiedział, "Widziałem jedną wersję i po tym zachorowałem. Fizycznie."

Chciałbym publicznie podziękować Ci za tak otwarte podejście do spraw GNU/GPL. To wszystko po 90 minutach rozmowy telefonicznej, z których przez 45 minut wykładałem istotne kwestie, problemy i zarzuty, a przez 20 minut rozmawialiśmy o pracy nad rozwiązaniami w najbliższej i dalszej przyszłości, a następnie wysłuchałem twoich uwag i pytañ, przerywanych moimi wstawkami.

Następnym razem nie będzie tak emocjonujących momentów, bo rozmowa odbędzie się osobiście, albo chociaż moja bateria w komórce będzie w pełni naładowana.

Ponieważ stwierdziłeś "Nie będę obiecywał niczego, czego nie mogę dotrzymać", to jest dobrze i będę starał się naprawić cały bałagan wynikły w przeszłości z winy obu stron.

Czekam na produkty Promise pracujące z Linuksem w istotny i produktywny sposób.

Proszę odpowiedz i popraw wszystko, co zostało przeze mnie przekręcone, albo potwierdź moje słowa. To pokaże wszystkim tutaj, że działamy w dobrej wierze.

Andre i ja naprawdę mieliśmy okazję miło porozmawiać przez telefon. Dziękuję Ci za poświęcenie swojego czasu na rozmowę ze mną i za ofertę pomocy. Tak jak powiedziałem przez telefon, angażujemy wiele naszych zasobów by wspierać Linuksa wypuszczając sterowniki oraz narzędzia dla nasych produktów, włączając w to FastTrak. Wiem, że istnieją plany wypuszczenia kodu źródłowego dla kart serii Ultra i SuperTrak, ale nie jestem teraz pewny że sposób w jaki chcemy wspierać FastTrak jest takim, który chcielibyście widzieć. Tak jak powiedziałem, ponieważ nie mogę gwarantowac niczego o czym sam nie decyduję, mogę działać na waszą prośbę. Będę próbował być adwokatem Promise w społeczności Linuksowej i sam będę stawał po stronie tej społeczności w Promise. Jeśli firma będzie miała uwagi, przekażę je wam i może wy będziecie mogli nam powiedzieć, czy mamy rację z tymi uwagami czy nie.

Chciałbym zachęcić wszystkich do kontaktowania się ze mną, przesyłania wszelkich sugestii i próśb. Tak jak powiedziałem Andre, nie obiecam niczego, czego nie będę mógł osobiście dostarczyć, ale zrobię wszystko co w mojej mocy by pomóc. Staram się także załatwić kontakt techniczny, żebyście nie musieli się się męczyć z marketingowcem, który nie rozumie nawet połowy z tego co mówicie ;).


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	5 Jun 2001 - 12 Jun 2001	(150 posts)	Status prac nad obsługą pamięci wirtualnej w 2.4
2.	8 Jun 2001	(6 posts)	Wykorzystanie nagłówków jądra w programach użytkownika
3.	8 Jun 2001 - 9 Jun 2001	(4 posts)	Stan prac nad ext3
4.	8 Jun 2001 - 11 Jun 2001	(10 posts)	Automatyczny wyłapywacz błędów
5.	10 Jun 2001 - 13 Jun 2001	(4 posts)	Nieudokumentowane symbole konfiguracyjne w 2.4.6pre2
6.	11 Jun 2001 - 13 Jun 2001	(9 posts)	Ograniczenia bigmema
7.	12 Jun 2001 - 13 Jun 2001	(10 posts)	Komercyjne łaty

Kernel Traffic #122 For 18 Jun 2001

By Zack Brown

Translated By: Maja Królikowska and Paweł Kot