Kernel Traffic #173 For 2002/07/01

Załączona łatka daje wsparcie dla schedulera O(1) na platformie SPARC64 w drzewie 2.4-ac. Oparta jest na mojej łatce z schedulerem O(1) z 2.5 przeniesionej przez Thomasa Duffy'ego.

Nie wiem, czy inne architektury w 2.4-ac wspierają już nowy algorytm szeregujący, ale będę pracował nad wysyłaniem diffów, jak tylko je dostanę lub zrobię...

Łatka jest dla 2.4.19-pre10-ac2, proszę, włącz ją.

Twoje kawałki kernel/sched.c dla sparc64 nie zostały przetestowane w żadnym jądrze. Co próbujesz osiągnąć? Wyłączają one bardzo ważną optymalizację SMP dla sparc64. To po prostu niedopuszczalne.

Łatki Ingo usuwające zastałe blokady muszą być zainstalowane wraz z łatkami pozwalającymi sparc64 działać bez zawieszania się, nie mogą być dodane oddzielnie.

Wiem, że są w porządku (obejrzałem je) i widziałem, że Linus je wziął, ale 2.5.22 jeszcze nie wyszło i nie widzę powodu, żeby spieszyć się z wysyłaniem ich Alanowi dla 2.4, jeśli możemy poczekać i upewnić się, że w 2.5 sprawują sie dobrze...

Moje podejście do przenoszenia O(1) z 2.5 -> 2.4 było bardzo ostrożne i jak dotąd sprawdzało się dobrze. Po co więc pośpiech?

Bardzo łatwo jest zrobić to na końcach, ale z htree możemy mieć naprawdę olbrzymie katalogi i posiadanie możliwości zatykania dziur w dowolnych miejscach będzie o wiele prostsze dla ext3 niż skracanie katalogów.

Przycinanie dużych katalogów przywraca koszmar truncate(), gdzie niezwiązane ze sobą operacje dyskowe muszą wyglądać jak jedność, nawet jeśli są rozdzielone na wiele transakcji. Stopniowe łączenie pozwala nam wiedzieć z wyprzedzeniem jak wiele bloków będziemy ruszali w czasie operacji, więc możemy zagwarantować zrobienie tego w jednej transakcji.

Jestem w 100% przekonany, że nie chciałbyś mieć ,,jednego jądra'' dla klastra, chciałbyś raczej mieć niezależne jądra z dobrą infrastrukturą komunikacyjną między nimi (np. globalny system plików i postarać się, aby sprawy sieciowe wyglądały tak samo).

Próba posiadania jednego jądra dla tysięcy węzłów jest po prostu szalona. Nawet jeśli system jest Numa i _mógłby_ to teoretycznie zrobić.

Ludzie od NuMA mogą wziąć pojedyncze jądra na, powiedzmy, 64+ węzłów, zanim ludzie się wściekną. Nie ma sposobu aby mieć jedno jądro na tysiącu CPU, pozostać zdrowym na umyśle i mieć sensowną wydajność przy typowych obciążeniach.

Zgoda.

Problem klastra obliczeniowego jest bardzo ciekawy. Ważne rzeczy na liście 'do zrobienia':

• Skalowalny, szybki system plików (Lustre wygląda dobrze)
• Punkty kontrolne na poziomie pod-aplikacyjnym.

Usługi, takie jak programy szeregujące, już istnieją.

Zadanie schedulera staje się dużo prostsze, a sam scheduler potężniejszy, gdy tylko dostanie możliwość usypiania procesów. Punkty kontrolne zapewniają trzy rzeczy. Możliwość wywłaszczenia zadań, możliwość migrowania procesów i możliwość wyratowania się z uszkodzeń węzła (zakładając, że uszkodzony sprzęt nie zniszczy punktów kontrolnych zadań).

Jak tylko rozwiązania problemów klastrowych zostaną dobrze zrozumiane, nie zdziwiłbym się, gdyby część ze wspierających je usług stała się częścią jądra, tak jak nfsd. Fragmenty rozproszonego systemu plików na pewno będą.

Podejrzewam, że punkty kontrolne procesów i wznawianie wyewoluują w coś jak wsparcie dla pthread. Z częścią kodu w przestrzeni użytkownika i jakimś ogólnym wsparciem w jądrze, każdy ze swoimi zadaniami. Jedynym wyzwaniem jest zapis/wznowienie komunikacji międzyprocesowej. Rzeczy typu przeniesienie połączenia tcp z jednego węzła na inne stanowią interesujące problemy.

Podejrzewam także, że większość ciężkich problemów, w których potrzebujemy pomocy jądra, posiada rozwiązania, które mogą być użyteczne w innych dziedzinach niż punkty kontrolne. W tej chwili mamy już farmy serwerów, które rozdzielają połączenia z pojedynczym adresem IP na węzły.

http://www.bitmover.com/cc-pitch

Od lat staram się zmusić Linusa do posłuchania o tym, a on wciąż wraca do wymęczonej kwestii SMP. DEC już to zrobił, Sun interesuje się tymi slajdami od kilku tygodni, więc może też to zrobią. Wtedy Linux może przyłączyć się do zabawy jak już stanie się najeżonym blokadami, z miękkim czasem rzeczywistym, z obsługą numa, zapuszonym śmietnikiem tak jak inne jądra, a my będzimy musieli znowu uporać się z hasłem ,,chodźcie, wynajdziemy Uniksa po raz trzeci w ciągu ostatnich 40 lat''. Jaka zabawa? Żadna.

Przepraszam za szorstkość, idźcie przczytać slajdy. Będę na OLS, chętnie podyskutuję z każdym, kto ma jakieś przemyślenia o tym. Paul McKenney z IBM przybył do San Francisco żeby o tym porozmawiać, przepuścił mnie przez 8 czy 9 godzinną sesję która wyglądała jak obrona doktoratu, a po próbach znalezienia dziur przyznał, że to być może jest dobry pomysł. Był na tyle uprzejmy, że spisał to co wyniósł, jest to tutaj.

Hmm. Odnoszę wrażenie, że Linux ma SMP głównie dlatego, że nie stało się jeszcze koszmarem. Linus tuż przed chwilką zauważył, że dla SMP istnieją limity skalowalności.

Co do cc-SMP.

1. Poza systemami dwuprocesorowymi, nikt nie robi SMP w sensownej cenie.
2. cc-SMP nie rozwiązuje niczego poza Twoim problemem z blokadami.

Przedstawiłeś swój pomysł. Być może będzie on przydatny. Ale w tej chwili nie jest to ważne. To, czego potrzebuję, to punkty kontrolne procesów. Reszta pojawi się w małych krokach, jak już to będzie.

Dla mnie naturalną rzeczą jest zacząć z klastrami, są tańsze i łatwiej dostępne niż SMP. Następnie trzeba popracować z oprogramowaniem klastrowym wprowadzając coraz mniejsze usprawnienia, aż będzie można traktować klaster jako pojedynczą maszynę. Wtedy łatwo będzie sprawdzić, co spisuje się lepiej w przypadku SMP.

Właśnie o to chodzi, duże klastry są ciekawym tematem badawczym, ale _nie_ jest winą Linuksa to, że się do nich nie skaluje.

Poruszanie kwestii SMP do upadłego ma sens dla 2-procesorowego SMP. Kiedy maszynki 64-ro procesorowe staną się powszedniością (Linux jest systemem operacyjnym dla powszechnego sprzętu), coś trzeba będzie zrobić. Kiedy grupy badawcze odpalają linuksa na tysiącu procesorów - jest to eksperyment. Nie sądzę, abyśmy mieli prawo do narzekania, że Linux kiepsko sprawuje się na tym poziomie - nie został zaprojektowany do tego.

Ma to sens dla dobrze dobranego systemu, gdzie dobre dobranie oznacza głównie sensowny koszt.

Dzisiaj oznacza to 2, może 4 procesory.

Rzeczy typy SMT (intel nazywa to ,,HT'') zwiększają to do 4/8. Jest po prostu _taniej_ robić tego typu wbudowane SMP.

Ważne jest to, co Cort nazywa ,,powszednością''. Nie ,,mała liczba CPU''. Linux koncentruje sie na SMP, bo jest to JEDYNA INTERESUJĄCA PLATFORMA SPRZĘTOWA w przestrzeni powszechności.

ccNuna i klastry nie są nawet na _radarze_ z punktu widzenia powszechności. Natomiast powszechne 4 i 8 procesorowe SMP jest odległe tylko o kilka lat.

Więc, ponieważ SMP jest tanie i efektywne, większość pracy nad skalowalnością jest wykonywana na SMP. A margines to po prostu margines. numa/klastry starają się używać podejść SMP, wiedząc, że są mniejszością, starają się wydźwignąć do powszechności.

I tak będzie w najbliższej przyszłości. Ludzie powinni po prostu zaakceptować ten fakt.

Jedyne, co może zmienić obecną sytuację, to możliwość, że pewne zagadnienia numa czy klastrów uogólnią się, stając się bardziej powszechne. Myślę na przykład o podejściu AMD do SMP w hammerach, czyli ,,lokalne pamięci'' z szybkim połączeniem między CPU. To o wiele bardziej NUMA niż przywykliśmy wśród PC.

Z drugiej strony, rozwój NUMA w kireunku upowszechnienia powoduje zwiększenie integracji, co za tym idzie _opóźnienia_ są tak małe, że potencjalne przyszłe, powszechne NUMA będą mogły być traktowane jak duże UMA/SMP.

Gwarantuję, że Linux będzie dobrze skalował się do 16 CPU, jak tylko staną się one powszechne. A reszta nie jest po prostu tak ważna.

Jedno, co jest pomijane, to to, że Linux potajemnie chce być mikrojądrem.

O, nie mam na myśli ścislej definicji mikrojądra, ale wciąż opieramy się na dogmacie ,,zrób to w przestrzeni użytkownika'', czy ,,zrób to w kontekście procesu'' (czyli przestrzeni użytkownika w jądrze).

Wystarczy spojrzeć na jądro -- nie jest już prostu sterowanym wydarzeniami, monolitycznym programem [tradycyjne podejście do jądra]. Linux polega na pewnej liczbie wątków jądra wykonujących różne asynchroniczne zadania. Od jakiegoś czasu mamy działających w przestrzeni użytkownika agentów zawiadujących fragmentami sprzętu, a ten trend będzie umocniony przez initramfs Ala.

Według mnie, jądro dąży do bycia zbiorem asynchronicznych zadań, co samo w sobie prowadzi do dużej równoległości. Sam sprzęt dąży do przyjaznego współgrania z innym sprzętem (przykłady: zwalnianie szyny na podstawie TCQ i współdzielenie przerwań), kolejny element równoległości.

Nie widzę przyszłości Linuksa jako pokręconego koszmaru blokad.

To nie jest filozofia mikrojądra, to filozofia dobrego Systemu Operacyjnego. Jeśli coś nie _musi_ być w jądrze, to lepiej, żeby nie było.

Zgadzam się z Tobą, że Linux już jest zbiorem luźno powiązanych, choć wysoce zależnych, asynchronicznych wątków. To powoduje, że analiza systemu jest bardzo trudna.

Nie wydaje mi się, aby w krótkim czasie Linuksowi groziło zostanie Solarisem. Linux stara sie działać na 1 do 4 procesorów i robi to całkiem dobrze. Większość rozsądnych ludzi zdaje sobie sprawę, jak wskazał Larry, że bieżący projekt nie będzie się skalował do 64 i więcej procesorów. To oczywiste, nie alarmujące. Kluczem jest zrozumienie, że Linux nie jest _pomyślany_ do skalowania się tak bardzo w chwili obecnej.

Popracowałem trochę z sugestią Larry'ego na temat skalowania Linuksa - jest bardzo sprytna i rozwiązuje problem w bardzo prosty i elegancki sposób. DEC zrobił to samo ze swoim Galaxy, ale za to napakował za dużo funkcji klastrowych i OpenVMS, tracąc tym samym całą wydajność uzyskaną przez bycie sprytnym. Jeśli chcecie prostego opisu tego pomysłu - jest to programowa wersja NORMA.

Idealnymi warunkami dla Linuksa są 2-4 procesory, i to nie powinno sie zmienić. Pójście dalej jest problemem. Wiele systemów poniosło klęskę dokładnie w taki sam sposób, próbując zmierzyć się z nim. Wystarczy po prostu zrobić klaster z linuksów na 2-4 procesorach (pokój pełen komputerów, duży 64 prockowy server IBM albo jakaś hybryda) i mamy proste rozwiązanie.

Przemyślenia owszem miałem. Bardzo długie. Dlatego nie zostało to zrobione. :)

Najbliższe temu, z rzeczy, które możesz osiągnąć w tej chwili, to jakiś wariant dwujądrowego monte, tj. uruchomienia nowego jądra z wyłączeniem wszystkich procesów, ale przynajmniej bez angażowania BIOSu.

Nowa infrastruktura swsup Pavela Macheka teoretycznie pozwala Ci zapisać stan systemu na dysk, więc jesteśmy już o wiele dalej niż byliśmy. Jeśli chciałbyś ponownie otworzyć tę puszkę robali, zacznij od kombinacji tych dwóch projektów:

http://falcon.sch.bme.hu/~seasons/linux/swsusp.html

http://sourceforge.net/projects/monte/

Największym problemem jest jednak możliwość zmiany struktur opisujących stan wraz ze zmianą jądra. Przetworzenie tych danych ze starej wersji do nowej nie może być zrobione automatycznie, ponieważ żadne narzędzie nie może wiedzieć, co dane zmiany OZNACZAJĄ, więc prawdopodobnie za każdym razem będziesz musiał napisać własny konwerter, odpluskwienie go będzie cokolwiek bolesne. (A jak uda ci się odpluskwić go w połowie, pojawi się NOWE jądro i będziesz musiał zaczynać od nowa...)

Oczywiście programowe wstrzymanie radzi sobie z problemami ze sterownikami, więc trochę rzeczy możesz sobie odpuścić. Migracja gorących połączeń sieciowych była już przez niektórych robiona, chociaż będziesz musiał się popytać, przez kogo. (Zapytaj tych opętanych bezpieczeństwem, oni uważają je za złą rzecz. :)

Nie ma rzeczy niemożliwych dla upartych osób, więc masz nawet szansę nas zadziwić (to całkiem dobry pomysł na zdobycie jakiegoś stopnia naukowego). Gorąca migracja nie jest NIEMOŻLIWA, jest tylko koszmarnie bolesna. Ale ten temat jest już obgadany (gdzieś pomiędzy ,,czy już jesteśmy, mamo?'' i ,,mogę kupić kucyka?''). Sprawdź listę dyskusyjną swsusp, może oni Cię wspomogą...

(Ludzie, którzy CHCĄ tego bajeru (zwłaszcza ci typu ,,ten system nigdy nie jest wyłączany'') są najmniej chętni do pracy nad delikatnymi błędami wynikłymi z konwersji, które ujawniają się dopiero po tygodniu działania systemu, gdy cron zaczyna wariować o 3 nad ranem. Kwestia tego, czy gorąca migracja jest bardziej niebezpieczna dla twoich danych niż interakcja pomiędzy osobowościami Andre i Marcina w warstwie ATAPI, pozostaje otwarta... :) Khmm. Tak...)

ROZSĄDNYM rozwiązaniem jest zawsze zaplanowanie krótkiego wyłączenia maszynki. Szalone rozwiązanie pociąga za sobą oddanie ogromnej ilości pieniędzy Sunowi czy IBM za moduły wymienialne w czasie pracy.

Klastry. Wątki migracji w klastrach to potencjalnie podobny problem. Spójrz na mosix i sprawy NUMA, jeśli poważnie o tym myślisz. Musisz ograniczyć proces do jego żywotnych danych, jak tylko możesz odebrać mu wszystkie zasoby - odbierz mu je, przenieś na partycję wymiany, zwolnij, itd. Jeśli możesz wstrzymać i zapisać działający proces w obrazie dyskowym (po prostu jako plik w systemie plików), w taki sposób, aby potem indywidualnie załadować wybrane (przy użyciu tego samego jądra), jesteś już w połowie drogi. Nie, nie jest to takie proste jak się wydaje. :)

To oczywiście po części prawda (Jestem pewien, że praca nad programowym wstrzymaniem ma związek z wyładowywaniem modułów).

Istnieje pewne drzewo zależności: proces potrzebuje zamontowanych systemów plików i otwartych uchwytów do stosu sieciowego itp., więc nie możesz odmontować systemów plików i wyładować sterowników, gdy są w użyciu. Usypianie działającego systemu i śledzenie wszystkich kawałków jakie są potrzebne, żeby złożyć go z powrotem, to wyzwanie.

Programowe wstrzymanie nie może zamrażać procesów indywidualnie do oddzielonych plików (to wiem), ale słyszałem teoretyczne rozmowy nt. dodania tego. (Nie wiem jakie są aktualne plany, pavel machek pewnie wie). Jeśli procesy będą mogły być zamrożone w sposób niezależny od jądra (tak, aby informacje o ich stanie mogły być przetworzone ze znanego formatu i wrzucone do działającego jądra), wtedy zmiana jądra ograniczy się do zapisania procesów na których ci zależy, wykonania dwujądrowego monte i przywrócenia procesów. Migracja procesów z jednej maszyny na inną w klastrze też będzie możliwa.

Jestem pewien, że nie jest to takie łatwe jak brzmi, ale zainteresowanie się programowym wstrzymaniem jest pierwszym, koniecznym krokiem. Jest to w końcu zapisanie procesów po kolei na dysk i przywrócenie ich potem. Jestem przekonany, że coś takiego dzieje się, gdy microsoft word zapisuje pliki *.doc (zapis struktur opisujących stan na dysk i dokładne odczytanie ich później, mając nadzieję, że ułożenia offsetów przez twój kompilator zgadzają się w przypadku zmiany wersji).

Ale przecież ludzie od star office rozpracowali to i (w większości) działa im to, bez dostępu do kodu źródłowego worda... :)

Hmm, co jest zaangażowane w zapis procesów na dysk? Oczywiście zaczynasz od wysłania mu sygnału zawieszenia. Potem następuje praca procesu. (Priorytety, itd.) Nieźle. Musisz zapisać wszystkie mapowania pamięci (nie tylko zawartość fizycznych i wyswapowanych stron pamięci (które powinny byc zapisane w pliku), ale również stany ochrony stron i podmapowane do pamięci pliki itd., tak, żebyś mógł wgrać je w odpowiednie miejsca pamięci później). Nie wiem ile ostatnie prace nad współdzieloną tablicą stron (daniel philips?) ZNACZĄ dla tego typu informacji.

Musisz oczywiście zapisać wszystkie otwarte uchwyty plików. (dla plików oznacza to pozycję, odpowiednie blokady itd. Dla zilionów rzeczy WYGLĄDAJĄCYCH jak pliki: potoków, gniazdek, urządzeń znakowych i blokowych, spodziewaj kodu dla przypadków specjalnych).

Potoki to zabawna kwestia: nie możesz po prostu zająć się jednym procesem. Czasami zazębiają się, i jeśli zabijesz jeden, więcej pójdzie za nim. Grupy wątków są łatwe do rozróżnienia, tak jak relacje dziecko/rodzic dzielące uchwyty plików, mapy pamięci i tego typu rzeczy, ale nawet proste "cat blah | less" oznacza dwa procesy połączone potokiem, które muszą zostać uśpione razem. (Popularny przykład z prawdziwego swiata: jednym z tych procesów będzie serwer X11, to nam daje KUPĘ zabawy. Dla wersji 1.00 są to oczywiste ,,rzeczy, których nie należy robić'', później można wprowadzić jakiś specjalny przypadek).

Jeśli bieżący uchwyt pliku jest przypisany do usuniętego pliku, musisz albo zrobić link do tego pliku gdzieś (niezbyt trudne, już mamy coś takiego w proc/###/fd) albo zachować zawartość pliku jako część obrazu procesu...

To sprowadza pytanie, jak przenośny powinien być obraz procesu. Zapomnij o zmianie jąder, myślę o działaniu systemu przez jakiś czas przed wznowieniem "zamrożonego" programu. Zmień nazwy kilku plikom i wznowienie zakręcone. Musisz wznawiać do tego samego systemu plików, jak ten, który opuszczałeś, bo jeśli będziesz miał otwarty uchwyt pliku do jakiegoś pliku lub urządzenia którego nie ma na wznowionym systemie, dostajesz scenariusz ,,przerwany potok'' (ponownie, wymuszenie odmontowania systemu plików może i tak spowodować ten problem, więc infrastruktura do radzenia sobie z tym będzie się musiała pojawić w pewnym momencie...)/

Ponowny start działającego systemu z tymi samymi podmountowanymi partycjami i, miejmy nadzieję, tym samym zestawem sterowników nie jest o wiele gorszy niż programowe wstrzymanie. Wykrycie brakującego pliku i mamy błąd wznowienia. Bardzo łatwy do wywołania, ale to problem użytkownika...

Jakie inne zasoby odnoszą się do procesu? Informacje o nim samym (ID użytkownika, uprawnienia), mapy pamięci, uchwyty plików... przypisane gniazdka... programy obsługi sygnałów i maski ... mapowania portów I/O i tym podobne, jeśli chodzi o roota...

To nie jest nierozwiązywalny problem, ale to JEST puszka robali. Prosta zmiana rodzica okazała sie tak skomplikowana, że zrobiono reparent_to_init (spójrz w kernel/sched.c).

Ktokolwiek podzielił arch/i386/kernel/setup.c i stworzył katalog CPU (bardzo dobry pomysł) dał ciała w conajmniej jednym miejscu:

*Zdefiniowane przez AMD* flagi CPUID ((0x80000001) nie są używane wyłącznie przez procesory AMD! W rzeczywistości, conajmniej AMD, Transmeta, Cyrix i VIA ich używają; nie wiem jak jest w przypadku Cenatura i Rise. Intel obsługuje te flagi od P4, jednakże zwracają one same zera.

Wg mnie, powinny one być przeniesione do generic_identify(). Jeśli ktoś ma coś przeciwko niech powie to teraz, bo wysyłam łatkę Linusowi.

Jest kilka sposobów usunięcia BKL z ext2 i ext3. Pierwszy to oczywiście wprowadzenie blokad dla każdego systemu plików zamiast brania BKL (nie wiem, czy Al zmienił lock_super() w 2.5 na prawdziwy semafor czy nie). Jak zauważył Andrew, potrzebna będzie blokada dla każdego dziennika, żeby zapewnić ich integralność. W tej chwili blokada systemu plików jest równoznaczna z blokadą dziennika, ale kiedy pojedyncze urządzenie robiące za dziennik będzie mogło być dzielone miedzy systemami plików, będą to inne blokady.

Dyskusję na temat skalowalności blokowania w warstwie dziennika pozostawiam Andrew i Stephenowi.

Wewnątrz systemu plików możemy dodawać konkretniejsze blokady - blokada superbloku z blokadami poszczególnych grup, a nawet blokady poszczególnych bitmap i tablic i-węzłów (bloków). Pozwoliłoby to na wielowątkowe operacje na i-węzłach i alokacje bloków, ale trzeba wymyślić sensowną strategię blokowania. Blokady bitmap mogą być dwustanowe, bo zajmujesz się bitmapami tylko jak chcesz je zmodyfikować. Blokady tablic i-węzłów powinny być blokadami odczyt/zapis.

Gdyby istniał mechanizm spróbuj-zablokować-do-zapisu dla indywidualnych bloków tablicy i-węzłów, można ominąć przetrzymywanie blokady przy tworzeniu plików przez wyszukanie pierwszego nie zablokowanego bloku w tablicy i-węzłów docelowej grupy (wśród setek bloków w każdej grupie przy domyślnych parametrach). Przy alokacji i-węzłów nie obchodzi Cię, który i-węzeł dostaniesz, o ile jest on w preferowanej grupie (a dla katalogów nawet to nie jest ważne). Przy kasowaniu i-węzłów otrzymasz losowe blokowanie i-węzłów, co jest usprawnieniem w stosunku do podejścia znajdź-pierwszy-niezablokowany (kosztem zabrudzenia większej liczby tablic i-węzłów).

Przetrzymywanie blokady superbloku przy aktualizowaniu liczników wolnych bloków i wolnych i-węzłów może być ominięte poprzez przechowywanie w pamięci ,,delt dla każdej z grup'', które zapisywane są na dysk raz na parę sekund lub w czasie statfs - zamiast wymagania wielu blokad dla każdego przydziału/zwolnienia bloku/i-węzła. Grupy już mają własne liczniki wolnych bloków i i-węzłów. Zbieżność tych pól z superblokiem będzie obsługiwana w czasie naprawy dziennika (czy to przez kernel czy e2fsck). Poza tymi dwoma polami mało jest zapisów do superbloku. (ext3 ma jeszcze listę sierot, modyfikowaną w czasie skracania i kiedy otwarty plik jest usuwany i kiedy taki plik jest zamykany).

Myślałem o wielowątkowym tworzeniu wpisów w pojedynczym katalogu. Miłą rzeczą w blokach katalogów ext2/ext3 jest to, że są odrębne i mogą być modyfikowane niezależnie. Dla zwykłych katalogów ext2/ext3 możesz uzyskać wielowątkowe usunięcia poprzez blokowanie każdego bloku katalogu. Przy tworzeniu potrzeba blokowania całego katalogu w celu uzyskania wyłączności na utworzenie, co z kolei jest tym samym jednowątkowym zachowaniem dla pojedynczego katalogu jakie mamy dzisiaj z i_sem przynależnym do katalogu.

Jednakże, jeśli używasz indeksowanych katalogów htree (co będziesz robił jeśli zależy Ci na skalowalności systemu plików), to będziesz miał tylko jeden blok, do którego można dodać plik, więc blokady dla bloków wystarczą również do tworzenia plików. Gdy liczba wpisów w katalogu rośnie (rośnie też liczba bloków katalogów), blokowanie robi się coraz bardziej szczegółowe - zyskujesz lepszą skalowalność z dużą liczbą katalogów, a to jest to, o co Ci chodzi.

Kolejne kroki dla ext2: pogapić się na następny zestaw wykresów od Antona, a potem spodziewam się usunięcia listy LRU bitmap z fs-private, listy LRU buforów przypisane do każdego CPU - żeby uniknąć przetrzymywania blokady mapowania urządzeń blokowych, blokady dla każdej grupy bloków i usunięcie lock_super z alokatora bloków.

Ale nie ma sensu tego robić w czasie, gdy zone->lock i pagemap_lru_lock sa na szczycie list. Poprawki dla obydwu są w trakcie wytwarzania.

ext2 jest niesamowicie prosty. Będzie niesamowicie skalowalny w 2.6.

Myślę, że z odrobiną ostrożności możemy osiągnąć lepszy stan. lock_journal może stać się blokadą odczyt/zapis chroniącą maszynę stanu transakcji, ponieważ istnieje tylko jedno miejsce --- wątek zapisu --- gdzie zmieniamy stan samej transakcji (np. z oczekującej na zapisywaną). Dla krótkotrwałych transformacji bufora, mamy już blokadę listy danych.

Jest kilka pośrednich typów operacji, takich jak do_get_write_access. To operacja na buforze, ale wymaga możliwości przydzielenia pamięci na starą wersję bufora, jeśli jesteśmy w trakcie zapisywania bh na dysk. Wszystkie te przypadki są już przygotowane na utratę BKL w trakcie przydzielania pamięci, więc nie ma problemu ze zrobieniem tego samego z krótkoterminową blokadą bufora; a jeśli journal_lock jest współbrany w takich miejscach, nie ma pilnej potrzeby zwalniania go w czasie malloc.

Nawet wątek zapisu może uniknąć blokowania dziennika w wielu miejscach --- musi mieć na niego wyłączność w takcie zmieniania globalnego stanu transkacji, ale gdy tylko manipuluje blokami zapisywanej transakcji, może obejść się z mniejszym blokowaniem.

Poza faktem, że rozwija się powoli, mógłbyś wyjaśnić jakie masz plany co do systemu konfiguracji?

W dniu dzisiejszym mamy trzy różne sposoby odczytu plików Config.in, wśród których xconfig jest najlepszym, ale też najbardziej krytycznym parserem/analizerem. Chcesz zastąpić je wszystkie czy jak?

Planuję zmianę dzisiejszej konfiguracji do nowego formatu (mam do tego narzędzie), który jest bardziej elastyczny i przechowuje wszystkie informacje potrzebne do skonfigurowania/zbudowania sterownika w jednym miejscu. W tej chwili wygląda to tak:

config BLK_DEV_SD
  depends SCSI
  tristate "SCSI disk support"
  help
  If you want to use a SCSI hard disk ...

Większa ilość informacji może byc dodana później.

Obecne parsery będą zastąpione jednym - właściwie to biblioteką, która wykonuje całą robotę i umożliwia różnym interfejsom użytkownika zachowywać się tak samo.