Kernel Traffic #151 For 21 Jan 2001

Chciałbym podziękować wszystkim osobom, które napisały do mnie listy elektroniczne z gratulacjami z okazji trzecich urodzin Kernel Traffic. Zauważył to nawet slashdot, co jest dla mnie miłą niespodzianką.

Dość zaskakującym mnie faktem jest to, że jednym z największych, choć rzadkich zarzutów wobec KT jest to, że nie jest to pełne streszczenie wydarzeñ na liście. W jednym z komentarzy na slashdocie zarzucano, że KT czasami pomija ważne wątki, jednocześnie zagłębiając się w szczegóły przy tych mniej istotnych.

Jest to niewątpliwie prawda. Przez cały czas, odkąd się tym zajmuję, ruch na liście wyniósł średnio 5,5 megabajtów tygodniowo i, moim zdaniem, prawie cały ten ruch jest opisywany. KT nie obejmuje dziesiątków dodatkowych list dyskusyjnych poświęconych mniejszym częściom jądra, czy niekoñczących się dyskusji na IRC-u, gdzie odbywa się wiele rzeczywistego rozwoju jądra. Kernel Traffic i inne publikacje związane z jądrem mogą dać niewiele więcej niż liźnięcie tego, co dzieje się przy rozwoju jądra. Jeśli chcesz wszystko dogłębnie zrozumieć, nie masz wyboru: musisz zapisać się na LKML i doświadczyć na sobie jej oczyszczających sił. Weź przykład ze mnie: to naprawdę warte wysiłku.

Celem KT jest prezentacja wątków, które mnie osobiście najbardziej zainteresują. A ja jestem najbardziej zainteresowany, w jaki sposób odbywa się proces rozwoju jądra. Jak są podejmowane decyzje? Kto jest zaangażowany? Czym jest rozwój wolnego oprogramowania? Model rozwoju narodził się razem z jądrem Linuksa. Wcześniej, mimo że istniały źródła udostępniane na zasadach GPL itp., powszechnie akceptowaną mądrością było to, iż oprogramowanie wysokiej jakości może być tworzone jedynie w małych grupach ekspertów pracujących przez dłuższy czas w odosobnieniu, udostępniających wyniki dopiero po miesiącach czy nawet latach swojej pracy. Ta metoda była stosowana również przy projektach GNU, tak jakby powstawały w prywatnych przedsiębiorstwach. Linus zanegował tę ideę, a większość jego metod można teraz spotkać dość powszechnie w organizacji prawie każdego projektu open source. Nawet komercyjne jednostki z większym bądź mniejszym powodeniem próbują symulować te procesy.

Procesy rozwoju cały czas się same rozwijają i próbuję ich szukać właśnie tam, gdzie się zaczęły. Nie wszystkie wątki, które opisuję koncentrują się na tym aspekcie, ponieważ wiele z projektów jądra nie da się opisać w tym ujęciu. Część streszczeñ wygląda bardziej jak anonsiki, które prezentują obecny stan prac nad odpowiednimi fragmentami jądra.

Mam nadzieję, że Kernel Traffic się podoba i jest interesujący. Jeśli niedociągnięcia i niedokładności skłaniają ludzi do zajrzenia głębiej, do prawdziwego forum dyskusyjnego jądra Linuksa, mogę uznać to za całkowity sukces.

There were 497 different contributors. 255 posted more than once. 213 posted last week too.

Poniższa łata implementuje kawałek projektu naprawdę szybkiego mechanizmu blokowania, który opisano pod tym adresem:

http://lwn.net/2001/0419/a/lt-semaphores.php3

W dołączonej paczce jest API dla poziomu użytkownika i kilka testowych programów. Nie zawracałem sobie jeszcze głowy jakimiś rzeczami w stylu skrótów, czy podpisów cyfrowych.

Wygląda na to, że działa (UP i686 i SMP), ale jest parę problemów:

Przecieka. W jaki sposób należy liczyć odwołania do fragmentów jądra? Czy mogą być dołączane do mapowania VM? Czy lockfs byłby zbyt kosztowny?
Nie ma timeoutu. Czy jest dostępne coś w stylu down_timeout()?
Nie robię:

if (kfs->user_address != fs)
goto bad_sem;

ponieważ nie wydaje mi się, aby to cokolwiek dodawało, a zapobiega umieszczaniu tych blokad w niepoprawionym pliku, czy też pamięci dzielonej SysV.

Czy to stanowi problem?

Na ostani punkt Linus Torvalds odpowiedział, że sugerowałby to jedynie jako dodatkowe sprawdzenie poprawności, które nie jest za bardzo wymagane. Co to wymagañ odnośnie timeoutów, powiedział, że do tej pory jeszcze nic takiego nie powstało w jądrze, ale teoretycznie cała wymagana infrastruktura jest dostępna. Wreszcie, mówiąc o wyciekach, oznajmił, że dodawanie liczników odwołañ do mapowañ VM byłoby akceptowalnym sposobem na upewnienie się, że cała pamięć została zwolniona we właściwym czasie. Dodał, że można "także dodać flagę przy wywoływaniu mmap (MAP_SEMAPHORE - inne uniksy już coś takiego mają), aby powiedzieć systemowi operacyjnemu o kwestiach spójności, które mogą się ujawnić na niektórych architekturach (na x86 to by było no-op)." On i Matthew wymienili kilka słów na temat implementacji zliczania odwołañ, aż Linus powiedział:

Zauważ, że są inne, potencjalnie elegantsze, rozwiązania. W szczególności, niektórym podoba się podejście ,,semafora jako deskryptora pliku'', a ja muszę przyznać, że mogą mieć rację. W takim przypadku najzwyczajniej przekazujesz deskryptor, jak ciasteczko i możesz na nim wykonać dup()/close(), czy co tam chcesz.

Może spróbujesz takiego podejścia? To nie jest tak odległe od tego, co już masz, a z pewnością nie będzie żadnych reperkusji związanych z bezpieczeñstwem...

Po krótkiej dyskusji poza listą, Matthew wysłał nowy kod i odbyła się techniczna dyskusja, w której udział wzięli Manfred Spraul, Matthew Kirkwood, Alan Cox i Rusty Russell.

Pamiętając o tym, że żadna łata nie znajdzie się w jądrze Linuksa zanim na LKML nie zaczną spływać pozytywne informacje o jej działaniu, Andre Hedrick przesłał prywatną wiadomość od Roba Radeza odnośnie łaty autorstwa Andre ide.2.4.16.12102001. Rob pisał: "Używam Twojej łaty ide.2.4.16.12102001 razem z kontrolerem Promise PDC20269, twardym dyskiem Maxtor 160GB i jądrem 2.4.17, i chciałem powiedzieć, że, jak dotąd, działa świetnie." Wiele innych osób potwierdziło, że kod Andre działa doskonale i poprosiło o włączenie jej do 2.4 i 2.5; w pewnym momencie Andre zauważył: "wiem, że sterownik jest stabilny i wydajny przy wykonywaniu operacji dyskowych. Zatem nie rozumiem całkowitego ignorowania go." Gdzie indziej Andrew Morton powiedział: "Spędziłem kilka godzin próbując doszukać się jakichś niedoróbek, ale nie znalazłem żadnych. Głosuję za włączeniem tego kodu do 2.5, a później, gdy udowodni że jest stabilny -- do 2.4.x-pre1." Oliver Xymoron wtrącił: "Wolałbym zrobić odwrotnie. Kod 2.4 jest bardziej przetestowany, 2.5 jest przeniesieniem w przód. W 2.5 cały czas zachodzą zmiany związane z urządzeniami blokowymi, zmiana kodu IDE spowodowałaby problemy w oddzieleniu zmian w warstwie urządzeñ blokowych i IDE. Umieśćmy ten kod w następnym 2.4.x-pre1."

Oleg Dorkin wysłał łatę (napisaną pierwotnie przez Andreasa Dilgera) do jądra 2.4, która rezerwowała miejsce dla nazwę woluminu i UUID w superbloku Reiserfs 3.6 i generowała losowy UUID dla woluminów przekonwertowanych przez jądro z formatu 3.5 do 3.6. Poprosił o szybkie włączenie łaty, ale Chris Mason powiedział: "Tego nie powinniśmy robić zanim nie ukaże się zaktualizowana (nie beta) wersja reiserfsprogs, która obsługuje te rzeczy." Oleg sądził, że nie ma sensu czekać z aplikowaniem łaty na obsługę z zewnątrz. Powiedział: "gdy ukażą się właściwe wersje reiserfsprogs i utils-linux, ludzie po prostu zaczną używać tych rzeczy." Ostrzegł też, że jeśli ukażą się narzędzia, które obsługuję jeszcze niezaimplementowane rzeczy w jądrze, mogą dziać się złe rzeczy. Dodał, że Hans Reiser także uważa, że nadeszła pora na tę łatę.

Chris odpowiedział, że aplikowanie łaty wymusiłoby zmiany w narzędziach z przestrzeni użytkownika, a stosowana polityka nie pozwala dokonywać takich zmian w trakcie stabilnej serii. Jednak dodał: "Programy zmieniają się tak szybko, że być może powinniśmy nagiąć tę zasadę. Innym przykładem jest łata ,,unlink truncate'', która nie powinna zostać wysłana do Marcelo, dopóki nie powstanie wersja nie-beta reiserfsprogs, która to rozumie. To jest taki sam przypadek (chociaż teraz mamy o wiele mniejszy problem)."

Oleg zauważył, że łata nie wymusza żadnych zmian w programach z przestrzeni użytkownika, ale "jeśli ktoś chce uaktualnić programy z własnej woli, nie możemy mu zabronić! ;))" Chris odpowiedział: "Chodzi o to, że nie powinniśmy dodawać nic do jądra, zanim nasz pakiet z narzędziami nie zacznie tego rozumieć. Tak, to prosty przypadek, ale jeśli chcemy nazywać reiserfs stabilnym, musimy zacząć przestrzegać jakichś zasad." Oleg odpowiedział, że w zasadzie ostatni pakiet reiserfsprogs rozumiał już nową ogranizację danych, ale nie był w stanie zmieniać zawartości pól. Chris, po przejrzeniu kodu, nie był w stanie zrozumieć, w jaki sposób narzędzia mogły zrozumieć nowy układ albo chociaż, czym jest UUID. Oleg powiedział: "Nie wiedziały o uuid jako takim, ale wiedziały, że w tym miejscu są przechowywane jakieś dane tekstowe."

W tym miejscu Oleg zauważył: "Widzę, że Marcelo nie włączył łaty do 2.4.18-pre3, więc mamy nieco więcej czasu na przygotowanie reiserfsprogs ;)" . Koniec wątku.

Adam J. Richter wysłał dużą łatę czyszczącą moduły SCSI w 2.5 i powiedział, że jeśli nie będzie obiekcji, wyśle ją w mniejszych kawałkach Linusowi Torvaldsowi. Alan Cox odpowiedział:

Specjalnie mówiłem, żeby nie ruszać starego sterownika NCR5380. Wziąłeś na wpół zepsuty sterownik, zepsułeś go do reszty i zaryzykowałeś uszkodzenie dysku u każdego kto użyje Twojej łaty.

To, co mnie najbardziej złości, to to, że specjalnie Ci mówiłem, żebyś nie łatał tego sterownika, ale, jeśli musisz już koniecznie coś z tym robić, wziął wersję z 2.4.18pre i przeniósł ją na 2.5. Zamiast tego straciłeś czas i próbowałeś uczynić przyszłe zmiany trudniejszymi.

Patrząc na zmiany, jest oczywiste, że nie masz pojęcia jak jest obsługiwane blokowanie w tym sterowniku, ani od czego ono zależy. Jeśli byś zrozumiał mechanizm blokowania, stwierdziłbyś, że poprawiasz zupełnie zepsutą wersję sterownika.

Ilu innych opiekunów zignorowałeś, próbując im wysłać nieprzetestowane łaty ich sterowników?

Adam zaoponował, mówiąc, że nigdy nie otrzymał takich instrukcji od Alana. Przeszukując swoje archiwum pocztowe, nie mógł znaleźć wiadomości, przypominającej tę, o której mówił Alan. Ale dodał: "Teraz jestem świadom Twoich wytycznych odnośnie użycia wersji sterownika NCR z jądra 2.4.18pre dla przyszłych wersji dla 2.5 i z chęcią się do nich zastosuję."

Alan przeprosił za pomylenie Adama z kim innym i zasugerował: "Sądzę, że będzie" (kod 2.4) "znacznie łatwiejszy do prześledzenia. Rzeczą, na którą musisz zwrócić uwagę, jest to, że kolejka urządzeñ do obsłużenia na przerwaniu jest nie per host, ale jest globalna dla sterownika. Reszta jest w miarę oczywista, ale zwróć uwagę na blokowanie podprocedur. Jeśli się pomylisz, sterownik będzie czasami wpadał w nieskoñczoną rekursję." Koniec wątku.

Brian Litzinger zauważył następujący błąd przy próbie załadowania modułu CIPE:

/lib/modules/2.4.17/misc/cipcb.o: Uwaga: moduły bez licencji zgodnej z GPL nie mogą używać symboli GPLONLY_

Zauważył, że CIPE jest dostępne na zasadach GPL i spytał: "Pamiętam, że na l-k kwestia GPLONLY_ była poruszana już kilkukrotnie, ale nie mam pojęcia co mam teraz zrobić. Czy ten problem jest właśnie tym spowodwany?" Alan Cox poinstruował:

Dodaj

MODULE_LICENSE("GPL");

do kodu cipe i wszystko będzie w porządku

Brian zrobił tak i zadziałało, a Olaf Titz zauważył, że poprawka była już zrobiona w drzewie CVS CIPE.

Andreas Haumer zgłosił: "Mam problemy z jądrem 2.2.20 SMP i płytą główną ASUS CUR-DLS. Widziałem podobne zgłoszenia w ciągu ostatnich paru miesięcy i sądziłem, że problem zostanie naprawiony w 2.2.20, ale nie jest." Benjamin LaHaise powiedział, że poprawka jest 2.4, a Andreas spytał, czy będzie przeniesiona do 2.2.21; Benjamin odparł: "Nie sądzę; poprawki w blokowaniu smp, to jeden z głównych celów 2.4, więc ,,przeniesienie'' ich do 2.2, to ponowne odkrywanie 2.4." Alan Cox także odpowiedział Andreasowi: "2.2 nie obsługuje SMP na chipach VIA, to nie jest też dobre jądro dla robaczywych układów VIA."

Ludzie dręczą mnie o drzewo -ac i to jest właśnie to, co mam w moim wewnętrznym jądrze, łata ll oraz zmiany w kodzie ide.

Większość z tych rzeczy po prostu czeka by dotrzeć do Marcelo, ale zawierają one na przykład quotę dla 32bitowych uidów, którą niektórzy ludzie uważają za dość krytyczną oraz VM rmap-11b, które ja uważam za dość istotne

(Marcelo, wyślę Ci te rzeczy osobno, jeśli są jakieś dodatkowe rzeczy, które chciałbyś mieć -- po prostu poproś)

Adam Kropelin zgłosił: "Żeby wszystko było pełne i kompletne, uruchomiłem na tej wersji mój wielki test transferu po FTP (szczegóły w wątku ,,Zapis na dysk w ostatnich jądrach''). Wyniki i obserwowane zachowanie były w sumie takie same jak dla 2.4.17, zarówno przy głównej gałęzi jak i z -rmap11a. Czas transferu wyniósł 6:56, ale zapis na dysk był nierówny. 2.4.13-ac7 ciągle wygrywa ze znaczącą przewagą." Alan odpowiedział: "To tak naprawdę bardzo użyteczna informacja. Świadczy raczej o tym, że różnica w wydajności bierze się z różnic w blokowej windzie WE/WY w starym drzewie ac (tym, którego Linus nienawidził ;)). Pytaniem jest teraz (i częścią powodów, dla których Linus tego nie lubił), dlaczego?" Benjamin LaHaise napisał: "Iirc, Linusowi po prostu nie podobały się niskie/wysokie poziomy dla uruchamiania i zatrzymywania WE/WY. Mi się one osobiście podobały i chciałem używać tego mechanizmu, by decydować kiedy przesyłać dodatkowe bloki z cache bufora na urządzenie (to dostarcza fajnych sposobów obsługi wsadów). Problem, który zapoczątkował ten cały bałagan był złożony z brakującego wake_up w warstwie blokowej oraz ogromnych opóźnieñ, których doświadczyliśmy przy długich kolejkach WE/WY i braku priorytetów. Strony krytyczne dla wymiany oraz ładowanie programów, tak samo jak zapis na dysku dokonywany w tle, muszą mieć podniesiony priorytet, tak by zachowanie interfejsu było lepsze. Oczywiście z wieloma poprawkami we fragmentach, w których czekamy na WE/WY, wprowadzonymi z vm gdzieś między 2.4.6 a 2.4.17, nie czekaliśmy aż tak długo na WE/WY, jak to było kiedyś. Ale opóźnienienie zapisu na dysk wciąż przeszkadza. W efekcie mamy wybór między przepustowością a opóźnieniami."

Robert Love ogłosił aktualizację pozwalającą używać jego łaty wywłaszczającej jądro z algorytmem szeregującym 0(1) autorstwa Ingo Molnara. Parę osób rzuciło się na nią, a William Lee Irwin II napisał: "Udało mi się uruchomić to na laptopie, nawet razem z rmap. Nie zachowywało się dziwnie. Oczywiście, działanie interaktywne jest wspaniałe, ale nie mierzyłem niczego precyzyjnie, bo mam sporo innych rzeczy do precyzyjnego zmierzenia, to musi jeszcze poczekać."

Nowy algorytm szeregujący wyłącza przerwania sprzętowe w trakcie wołania context_switch. _switch_to z UMLa wymaga, by były one włączone, gdy jest wołany i strasznie się psuje, gdy tak nie jest.

Ponieważ UML ma proces dla każdego wątku UMLa, to SIGIO musi być przekazywane z jednego procesu do następnego w trakcie przełączania kontekstu. SIGIO, które przychodzi w trakcie przerwy między wyłączeniem przerwañ a ich przekazywaniem do następnego procesu będzie zgubione w momencie, gdy proces przestanie mieć kontekst. To się zdarza dość regularnie i powoduje zawieszenia, bo niektóre procesy czekają na dyskowe wejście/wyjście, które nigdy nie nastąpi, bo proces, który był o tym zawiadamiany jest wyłączony.

W związku z tym czy jest możliwe włączenie przerwañ sprzętowyuch w trakcie wołania _switch_to?

Davide Libenzi podesłał poprawkę, która wydawała się działać, ale Ingo Molnar zauważył, że nie działa ona dla systemów SMP. W innym miejscu Ingo znowu odpowiedział na prośbę Jeffa, mówiąc:

niestety nie da się tego zrobić ze względu na exit(), ptrace() i inne rzeczy związane z SMP. Na SMP, ,,poprzednie'' zadanie jest chronione przez specjalną blokadę. Jeśli dokonamy przełączenia kontekstu poza tą blokadą, to zadanie to może być zwolnione na na innym CPU, gdy tak naprawdę jest wciąż w użyciu.

są także inne poważne następstwa:

current->processor nie jest dłużej poprawny dla handlerów przerwañ.
CPU mogłoby wykonywać ,,poprzednie'' zadanie zanim zostanie z tego wyłączone (niby nic, ale blokada runqueue powstrzymuje load balancer przed zabraniem tego zadania z kolejki).

w 2.4 zaimplementowałem przełączenia kontekstowe z włączoną obsługą przewrañ. Aby zrobić to poprawnie potrzebujemy inaczej wprowadzić __schedule_tail() i robić task_lock/task_unlock, by uzyskać atomowy charakter przełączania kontekstów innymi sposobami niż lokalne kolejki działających procesów. Zrobilem to w 2.4, bo pojemność globalnych kolejek była naprawdę problemem dla pewnych obciązeñ i nawet narzut na odblokowywanie zadañ był tego wart. Z algorytmem szeregującym 0(1) problem ten nie istnieje.

możemy włączyć przerwania na UP, bo UP jest specjalne, wyłączanie przerwañ w nim to istota taniej ,,globalnej blokady przerwañ''. Ale to nie pomaga wiele w sytuacji SMP/UML.

proponowałbym znalezienie jakiegoś innego rozwiązania dla UML, innego oprócz sygnałów. __switch_to jest bardzo wewnętrzną funcją, która może być wołana z wyłączonymi blokadami, nie możemy tylko zagwarantować, że będzie wołana, gdy przerwania sprzętowe będą włączone. Sygnały są czymś takim, co często okazuje się ,,ciężkie'', generalnie nie można uznać, że są to operacje atomowe.

Sugerujesz, żeby zaimplementować przerwania przy pomocy innego mechanizmu niż sygnały? A co nam pozostaje?

W każdym wypadku, wydaje mi się, że _switch_to powinno sprawdzać, czy są jakieś oczekujące SIGIO i, jeśli tylko są, przesyłać nadchodzącemu procesowi sygnał SIGIO. Wydaje się, że to rozwiązuje kwestię.


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

1.	7 Jan 2002 - 13 Jan 2002	(15 posts)	Implementacja lekkich semaforów dla przestrzeni użytkownika
2.	8 Jan 2002 - 11 Jan 2002	(20 posts)	Łata IDE
3.	9 Jan 2002 - 11 Jan 2002	(9 posts)	Sprawdzanie stabilności interfejsu 2.4 w odniesieniu do ReiserFS
4.	11 Jan 2002	(7 posts)	Lekkie nieporozumienia deweloperów przy opiece nad NCR5380
5.	11 Jan 2002 - 12 Jan 2002	(6 posts)	Określanie licencji modułu w kodzie
6.	12 Jan 2002 - 13 Jan 2002	(11 posts)	Problemy z obsługą SMP w 2.2
7.	13 Jan 2002 - 14 Jan 2002	(13 posts)	Alan kontynuuje -ac dla 2.4
8.	13 Jan 2002 - 15 Jan 2002	(8 posts)	Połączenie łaty wywłaszczającej jądro z nowym algorytmem szeregującym
9.	13 Jan 2002 - 14 Jan 2002	(7 posts)	User-Mode Linux i nowy algorytm szeregujący

Kernel Traffic #151 For 21 Jan 2001

By Zack Brown

Translated By: Maja Królikowska and Paweł Kot