Kernel Traffic #177 For 2002/07/29

tak - 'synchroniczne budzenie' to forma szeregowania grup. Chodzi w tym o to, aby wykorzystać rzeczywistą informację o komunikacji międzyprocesowej do zmigrowania 'związanych' ze sobą zadań na ten sam procesor. Odbywa się zatem automatycznie, nie ma potrzeby formalnego definiowania przynależności procesu do 'grupy'.

(inny rodzaj 'szeregowania grup' może być uzyskany przy pomocy dowiązywania 'macierzystego' procesu do pojedynczego procesora -- wszystkie jego potomki zostaną przypisane do tego samego procesora.)

Byłem zaangażowany w implementację szeregowania grupowego w klastrze SP2 składającym się z IBM 340 w Lawrence Livermore National Lab. Niezależnie od implementacji, można pokazać, że można zwiększyć całkowite wykorzystanie systemu z ~60% do ~90% w przypadku, gdy użyjemy szeregowania grupowego, zamiast szeregowania FIFO, które zostało by użyte w przeciwnym wypadku na dedykowanej maszynie. Uzykaliśmy tony prac na ten temat.

Wygląda na to, że wystarczy zatrzymać aplikacje na większej ziarnistości i zrobić to przy pomocy demona w przestrzeni użytkownika. Scheduler jądra będzie szeregował działające wątki, których, przy ustalonym U-Sched, zawsze będzie ograniczona liczba.

Cieszę się, że podniosłeś ten problem. Chciałbym mieć ogólne wywołanie zwrotne na to. AIX miał/ma funkcję obsługi zmiany procesu, która jest wołana na początku/przy wyjściu.

Ten pomysł w Linuksie mogłby zostać zrealizowany przez ogólną funkcję określaną przez pewien moduł... to powinno wystarczyć i nie zepsuć obsługi innych rzeczy. Na przykład w przypadku wystąpienia szybkiej komunikacji na poziomie użytkownika (na przykład czasem aktualny proces mógłby być zaznaczany przez to, co obsługuje komunikację).

Czy Halloween jest ostatecznym terminem przesyłania łatek, czy ostatecznym terminem ich włączania? Jeśli prześlę reiser4 w dniu Halloween, zgodnie z jakąś strefą czasową ;-), to czy zmieszczę się w terminie i zostanie to włączone do 2.6, nawet jeśli moje łatki poczekają kilka miesięcy w kolejce wszystkich łat wysłanych w Halloween?

Rozumiem, że im wcześniej, tym lepiej i jeśli będę mógł to wyślę je wcześniej, ale nawet jeśli będziemy mieć rdzeń reiser4 (który będzie robił wszystko to, co V3, ale szybciej i będzie wmontowany w infrastrukturę wtyczek) przed Halloween, to niewątpliwie dodamy parę rzeczy i poprawek już po jego przygotowaniu i będziemy chcieli je przesłać w ostatniej chwili.

rozumiem to tak, że jeśli pewne istotne zmiany nie będą włączone do jądra przed Halloween, nie zostaną już zaakceptowane aż do 2.7. Ten ostateczny termin ogłoszono tak wcześnie w nadziei, że ludzie będą mieli sporo czasu by przesłać rzeczy, które są gotowe do włączenia, w przeciwieństwie do sytuacji, w której spieszyliby się z wysyłaniem wszystkiego w chwili, w której ogłoszone zostałoby ,,zamrożenie''.

Jeśli (a wszyscy mamy taką nadzieję) ważne rzeczy będą w ciągu najbliższysch kilku miesięcy dodawane stopniowo do jądra rozwojowego, może nie wszystkie użycia i testy, które mają obecnie miejsce zostaną zagubione, gdy całe jądro zostanie całkowicie zmienione ze względu na ogromny ciężar gatunkowy łatek.

To może nawet oznaczać, że nie będzie dodatkowego roku, w którym rozmaite cechy (i błędy) będą dodawane do ,,zamrożonego'' jądra i będziemy mogli wcześniej zacząć pracę nad 2.7.

Tak jak zawsze, wyobrażam sobie, że tak długo jak masz pewne istotne zmiany 2.5 przed zamrożeniem, to nie będzie niemożliwe dodanie osobnych rzeczy, takich jak systemy plików czy sterowniki, także po zamrożeniu.

Z całym moim egocentryzmem, sądzę, że bardziej sensowne byłoby ustalenie ostatecznego terminu podsyłania łat, niż ich akceptacji, bo dzięki temu wszystko byłoby bardziej przewidywalne dla osób podsyłających łatki i pozwoliłoby uniknąć niezamierzonego niezauważenia dobrych łatek od mało widocznych persons ze względu na natłok łatek w październiku.

Wcześniejsze ogłoszenie ostatecznego terminu jest dobre, ale ustalenie, że jest to ostateczny termin dla czegoś, nad czym panują osoby podsyłające łatki (czas wysłania, a nie czas akceptacji), byłoby nawet lepsze.

Zgodziłbym się, z wyjątkiem tego, że to nie nakłada żadnej odpowiedzialności na podsyłających łatki, by przesyłali swoje dzieła wcześniej i powoduje ten sam problem, który pojawia się przy nieogłaszaniu tych terminów: nawał łatek w jednym momencie.

Zauważ, że ,,zaakceptowane'' może się okazać błędnym terminem - nie umiem stwierdzić, czy to oznacza, że Linus otrzymał daną łatkę, czy oznacza to, że jest ona już w drzewie jądra.

Zwróć też uwagę, że nie było mnie na kernel summit, więc wszystko to co piszę usłyszałem od innych.

Chodzi o obie rzeczy. Wszyscy wiemy, że Linus nie ma czasu pilnować przenoszenia na coraz nowsze wersje setek naszych łatek, może jedynie włączać tylko te łatki, które dają się nałożyć na dokładnie takie jądro, jakie ma właśnie danego dnia.

To (oraz fakt, że Linus dostaje dużo za dużo listów i łatek, by patrzeć na stare rzeczy) jest ograniczniem na to, żeby Halloween było ostatecznym terminem zarówno dla przesyłania, jak i dla akceptacji łatek.

Taką mam nadzieję.

Mam nadzieję, że zamrożenie planowane na Halloween będzie prawdziwym zamrożeniem dla nowości. Nic nie jest bardziej frustrujące niż posiadanie ,,stabilnego jądra'', którego co druga wersja jest zepsuta przez kolejne elementy.

Jeśli się wszyscy powstrzymamy, to 2.6 będzie wkrótce stabilne, a 2.7 ruszy krótko po tym. Przeniesienie ,,istotnych'' cech z 2.7 na _stabilne_ 2.6 będzie znacznie łatwiejsze niż próby stabilizowania 2.6-pre, które jest pełne po brzegi niezupełnie jeszcze stabilnych elementów.

ta łatka, na najnowsze 2.5.27, zbudowana jest na łacie, która pozwala funkcji kmem_cache_shrink zwracać liczbę zwolnionych stron. Wartość ta jest używana jako wartość zwracana przez funkcję shrink_dcache_memory i inne takie.

Jest to użyteczne, nie tylko po prostu ze względu na dokładniejsze wykrywanie OOM, ale także jako przygotowanie do wstawienia tych stron na listę LRU. Pierwszym autorem tej zmiany jest Ed Tomlinson.

Nie zgadzam się z całym tym podejściem, w którym shrink_cache() zwraca liczbę zwolnionych stron.

Ta liczba nie ma żadnego znaczenia, bo nie jest nijak związana z faktycznymi strefami pamięci, które są wymuszane (obecnie, strefy pamięci są prawie zawsze ZONE_NOMRAL, co jest poprawne, ale jest to raczej czyste szczęście niż coś, co można zakładać).

Dużo bardziej interesowałoby mnie podejście typu ,,włóż strony cache na listę zabrudzonych stron tak, by wymuszanie pamięci wypchnęło je w porządku LRU''. Ktoś już miał takie wstępne łatki.

To pozwala _pozbyć_ się dcache_shrink() i tym podobnych, zamiast sprawiać, że zwracają one liczby, które nic nie znaczą.

Uwaga na boku: sądzę oczywiście, że to jest właśnie to, co należy zrobić, ale jest dużo bardziej ,,interesująca'' zmiana do zrobienia. Co z tego wynika, bardziej podobałoby mi się, gdyby to przeszło odpowiednimi kanałami (najprawdopodobniej przez Andrew) i zostało szerzej przetestowane, przynajmniej w formie CFT na linux-kernel.

[ A może to już było w 2.4.x w którymś z głównych drzew? (W tym przypadku rozluźniam mój argument o potrzebie testowania, potrzebne jest ono tylko do sprawdzenia, czy przeniesienie na nowe wersje działa). ]

Propoponowałbym unikanie dodatkowych zmian w VM aż do chwili, w której będziemy mieć rozwiązania następujących rzeczy:

2: Zadziała z pte-highmem (Bill Irwin się do tego zgłosił)

4: pte_chains przesunięte też do highmem (chyba Bill)

6: być może GC we wracających stronach w pte_chain. (Wydaje się, że nie da się tego uniknąć. Rik?)

Szczególnie pte_chains w highmem. Fakt, że nie udaje się tego naprawić hamuje użycie rmap na dużych maszynach z ia32, co powoduje, że jej w ogóle nie ma.

Jeśli możemy mieć coś w zamian, co działa w sposób możliwy do zaakceptowania na maszynach Martina Bligha i przekonamy się, że zyski ze stosowania rmap (jakiekolwiek by nie były ;)) są ważniejsze od problemów, które nie zostały jeszcze zakodowane, to działajmy z tym dalej. Ale do tego momentu dodawanie nowych rzeczy do VM powoduje tylko, że trudniej jest zrobić 'patch -R'.

Łatka ta implementuje restrykcyjną alokację pamięci wirtualnej dla rmap. Restrykcyjna alokacja łączy rejestrację przestrzeni adresowej z zasadą restrykcyjnego wykonania, aby mieć pewność, że cała przyznana pamięć zostanie zwrócona, co w konsekwencji wyeliminuje błędy braku pamięci (OOM). Wszystkie błędy obsługi pamięci powinny być przeniesione do procedur alokacji - dostęp do strony pamięci nie powinien nigdy prowadzić do unicestwienia procesu.

Nowa polityka restrykcyjnej alokacji pamięci została zaimplementowana za pomocą sysctl.

Ma ona niewielki wpływ na resztę kodu i nie zmienia zachowania systemu z domyślną polityką alokacji. Rik wyraził swoje poparcie w tej sprawie.

Łata oparta jest na rozwiązaniach Alana Coxa dla 2.4-ac z pewnymi przeróbkami i nowym trybem alokacji pamięci dla ,,bezswappowych'' maszyn. High Dickins dostarczył także małe poprawki dla shmfs.

Łatka jest przeznaczona dla 2.5.27

Wobec zmian w plikach, zmiana nagłówków mm/*.c w celu załączenia deklaracji GPL jest częścią mojej łatki. Kod podesłany przez Red Hat jest na licencji GPL i nie ma żadnej gwarancji, że poszczególne jego części nadają się do użycia. Gdy im odpowiadacie, proszę, załączcie dodane przeze mnie nagłówki GPL albo pisemną deklarację, że bierzecie całą odpowiedzialność za błędne działanie i tym podobne. Jeżeli zmieniłeś coś w kodzie, dodaj siebie także do listy **zasłużonych** (ang. credits).

Klauzule GPL o braku jakichkolwiek gwarancji zostały dodane bezpośrednio do pliku, ponieważ jest to właściwe dla nich miejsce.

To jest ewidentna nadmiarowość. One _NIE_ powinny były się tam znaleźć.

Jeżeli potrzebujesz prawnych deklaracji itp., to umieszczaj je w plikach, których jesteś 100% właścicielem, a nie do tych, którymi opiekują się inne osoby. Albo dodaj je na końcu pliku, gdzie nie są zbytnio widoczne. Możesz też dodać formułkę: ,,przeczytaj licencję GPL w pliku COPYING'' ale nie dodawaj ton śmieci do ważnych plików jądra.

Nie ma korzyści z bycia prawnikiem w plikach .c.

Dobrze. Nie znoszę sytuacji w których tak wielu ludzi sądzi, że dodanie 15-to linijkowej informacji o prawach autorskich do pliku uczyni ten plik ,,bardziej poprawnym''. Jedyne, co to zmienia, to fakt nadania prawnikom poszczególnych korporacji ,,punktu zaczepienia'' oraz wyeksponowania tego w ,,cennym'' miejscu zaraz po otwarciu pliku, zamiast informacji o przeznaczeniu źródeł (oraz informacji o autorach/twórcach/opiekunach).

Trochę off-topic, ale ciągle o tym samym: Nie znoszę również ton historii zmian które już nie mają związku ze źródłami (ponieważ zmiany już je _zastąpiły_, heh!). Listy zmian w źródłach są użyteczne jako źródło informacji o tym, kto pracował nad kodem, lecz wydaje się, że niektórzy ludzie zaczynają właśnie od nich na początku swej ,,Wielkiej Powieści''.

Mam nadzieję, że jedną z rzeczy do której przyczynił się BK jest mniejsze zaangażowanie w tworzenie historii zmian w plikach C i większy wkład w wyjaśnianie mi ich przeznaczenia w e-mailach, w których je dostaję. W jakim zakresie są one w formacie dzięki któremu możesz ujrzeć obraz ,,teraz i potem'', a nie mieć odczucie, iż ,,to wyglądało przedtem inaczej''? - no cóż, HMM!

Przygotowałem skrypty, które mogą być użyteczne jako bramka między bitkeeperem a cvs-em. Używam ich obecnie na nl.linux.org (jak to możecie zobaczyć, przyglądając się bliżej). Jeszcze nie ustaliłem jak pokazywać światu uzyskane w ten sposób repozytorium CVS.

[Skrypty są w CVS-ie pod adresem: www.sf.net/projects/linux25.]

Mam nadzieję, że się komuś przydadzą...