Kernel Traffic #161 For 2002/04/07

Oto łata na jądro, która obsługuje wielowątkowe zrzuty pamięci, opracowana przez Marka Grossa (Intel, mgross@unix-os.sc.intel.com) i Vamsi Krishnę (IBM, vamsi_krishna@in.ibm.com).

Łata pozwalająca na wielowątkowe zrzuty pamięci dla 2.4.17:

• funkcjonalność wielowątkowych zrzutów pamięci jest udostępniona przez nowy sysctl (0 = wyłączone, 1 = włączone).
• Zrzut pamięci jest rozpoczynany przez pierwszy wątek, który dostanie sygnał
• Wątki są znajdowane przez przechodzenie po całej liście zadań w poszukiwaniu zadań z pasującym mm, jako że to się wydaje być jedynym skutecznym sposobem na lokalizację innych wątków danego zadania. W zasadzie uważam, że jest to jedyny sposób, zanim wszystkie biblioteki z przestrzeni użytkownika przejdą na używanie grup wątków dostarczanych przez jądro linuksa (CLONE_THREAD).
• Wykonanie innych wątków jest wstrzymywane podczas zrzucania pamięci tak, by poprawić dokładność zrzutów. Wykonywane jest to bez zmieniania stanu zadania. Ustawiamy na 0 cpus_allowed w strukturze zadania, by temu zadaniu nie był przydzielany czas procesora i przywracamy wartość -1 by wznowić jego wykonanie. To rozwiązanie ma taką zaletę, że jego poprawne działanie zupełnie nie zależy od przestrzeni użytkownika. Moim zdaniem wysyłanie SIGSTOP w celu zatrzymania innych wątków nie działa, jeśli proces jest uruchamiany z debuggera. Jedyny problem z używaniem cpus_allowed to taki, że możemy stracić powiązania między zadaniami podczas brania zrzutu pamięci. Jenakże nie jest to wielki problem, bo zadanie i tak umrze dość szybko, dlatego właśnie najpierw jest brany zrzut pamięci.
• Obsługa rejestrów SSE w zrzucie pamięci
• Poprawki/reorganizacja kodu - podział na mniejsze funkcje. Główna funkcja, elf_core_dump() została zreorganizowana/uporządkowana przez przesunięcie zawartości elfhdr, prstatus, psinfo i notes do oddzielnych funkcji tak, by ta bardzo długa funkcja była trochę bardziej czytelna i by dało się wykorzystać wiele razy kod z funkcjami zrzucającymi stan innych wątków.
• Łatwo przenieść łatę na inne architektury. By to zrobić wystarczy mieć:
  ELF_CORE_COPY_TASK_REG - by kopiować rejestry właściwe dla zadania
  ELF_CORE_COPY_FPREGS - by kopiować rejestry zmiennoprzecinkowe i
  ELF_CORE_COPY_XFPREGS - by kopiować rozszerzone rejestry fp (SSE), jeśli są obecne
  ELF_CORE_SYNC - by synchronizować stan fpu innych procesorów w systemach SMP, jeśli to jest wymagane przez szczególną architekturę. Przeczytaj łatkę w celu uzyskania większej liczby szczegółów.
• Bazowaliśmy na łatach tcore Johna Jonesa oraz Jasona Villarreala, od nich zaczęliśmy, ale je istotnie przerobiliśmy. Ta łata jest zupełnie różna od ich łaty w prawie wszystkich aspektach.

Obecna lista TODO:

• Być może usunięcie reschedule_other_cpus w suspend_other_threads i zrobienie tego jako części ELF_CORE_SYNC. Przerobienie schedulera na inne CPU w sposób, w jaki działa obecna łata może być przesadą, bo chodzi przecież tylko o dokładne pliki ze zrzutem. Jakieś pomysły?
• Przeniesienie na 2.5.x, szczególnie sposobu wstrzymania innych wątków od wykonania w czasie zrzucania
• Skrócenie szukania innych wątków w pętli przez liczenie znalezionych zadań i wychodzenie z pętli for_each_task, gdy jest równe z current->mm->mm_users.

Uwagi dotyczące używania tej łatki:

GDB 5.1 działa z produkowanymi w ten sposób plikami ze zrzutami, ale dla Red Hata 7.2 tylko wtedy, gdy biblioteka /lib/i686/libpthread.so jest ukryta. Okazuje się, że dla RedHata na IA32 istnieją dwa pliki libpthread.so. Jeśli załadowane jest /lib/i686/libpthread.so, to debugowanie post mortem przy pomocy gdb nie będzie działać. Nie rozumiem o co w tym chodzi, ale tak się dzieje. Ukryj /lib/i686/libpthread.so, tak, żeby podczas debugowania ładowana była /lib/libpthread.so, w ten sposób debugger będzie działał z plkiem zrzutu. Wszystkie przepowiednie w tej kwestii będą mile widziane. To zachowanie jest dla nas bardzo tajemnicze.

Dzięki Bharatowi B Rao(IBM) za pomoc w opracowaniu rejestrów FPU i testowanie oraz Suparnie Bhattacharya(IBM) za dyskusje na temat projektu.

Dzięki Tony'emu Luckowi (Intel) i Junowi Nakajima (Intel) za pomoc przy przeglądaniu i projektowaniu implementacji suspend_other_threads.

Narazie łata jest dostępna tylko dla i386, była testowana na systemach 1P-P4, 2P-P4, i 4P-PIII. Nie znalazłem do tej pory żadnych błędów, YMMV.

Łata jest dostępna dla jądra w wersji 2.4.17. Przeniesiemy ją na najnowsze wersje jądra, jeśli będzie zainteresowanie.

Wygląda na to, że mamy zły dysk, sprawdzam właśnie dyski by stwierdzić, czy to główny, czy zapasowy. Uruchomię sprawdzanie na wszystkich repozytoriach, jeśli fsck nie znajdzie problemu, może zatem minąć parę godzin zanim serwer będzie dostępny.

W nie tak znowu dalekiej przyszłości przeniesiemy dysk zapasowy na inną maszynę, tak byśmy po prostu mogli zamienić komputery gdy takie coś się zdarzy, ale teraz będziecie musieli trochę poczekać.

Straciliśmy rzeczywiście dysk główny (IBM 40GB, zaczynam tracić cały szacunek, który miałem dla dysków IBM, ten jest jednym z wielu, które mi nawaliły). Odtworzyłem dane z dysku zapasowego, a w trakcie tego procesu przerobiłem hardlinki między drzewami jądra, co pozwoliło zaoszczędzić około 5GB (miło). Wszystkie drzewa, która są teraz na bkbits.net dają się bez problemu wyciągać, co oznacza, że BK myśli, że wszystkie pliki tam są i że sumy kontrolne są prawidłowe. To wskazuje, że jesteśmy w dobrej formie.

Nie byłbym zaskoczony, jeśli zdarzyłyby się jakieś problemy z prawami dostępu; poślij list na support@bitmover.com, jeśli takie ci się zdarzą, a my to naprawimy, jak tylko się o nich dowiemy. Tak naprawdę to wiem, że mamy problemy z prawami dostępu, ale ponieważ pracowałem nad tym od 12 godzin, to wrócę do tego jutro.

Jest para drzew, które straciły pliki, oba w linuxvm.bkbits.net Ricka, podejrzewam, że ta strata spowodowana jest przerwanym klonowaniem. Są to:
bk://linuxvm.bkits.net/linux-2.5-vmtidbits
bk://linuxvm.bkits.net/linux-2.5-writethrot
Rik, pingnij mnie, jeśli potrzebujesz pomocy w uporządkowaniu tego.

Drzewu ppc wydaje się brakować linuxppc_2_4, Paul/Tom/Troy/Cort, gdzie ono jest? Podejrzewam, że chcielibyście mieć z powrotem tu kopię, więc jeśli jesteś osobą od PPC i ostatnio uaktualniałeś wersję linuxppc_2_4, wstrzymaj się. Dojdziemy co się stało na liście ppc.

Zgubiliśmy trochę kluczy ssh. Zrobiliśmy ich kopię zapasową chwilę przedtem, ale nie udało nam się złapać wszystkich. Poniżej jest lista, przyślijcie mi listy z waszym kluczem ssh / nazwą projektu i odtworzę je ręcznie. Mamy już plany jak z tym problemem sobie poradzić, tak by więcej się nie pojawił.

Wybaczcie długi czas niedziałania, tak ja wszyscy, my też walczymy z recesją i nie umieściliśmy jeszcze na miejscu zapasowego dysku. Kupiliśmy je, kupiłem nawet dziesięć zapasowych pudełek na tego rodzaju wypadki, ale byłem zbyt zajęty, by je umieścić w odpowiednim miejscu. Zrobimy to, wiemy, że ludziom na tym zależy.

Oto lista projektów, w których brakuje kluczy ssh:

bcrlbits
freebsd-dvb (być może to nie Linux, nie? :)
lia64
linux-mtd
linux-srn
linux24 (wydaje mi się, że ten już umarł, mam rację Marcelo?)
ltr
misc
nonblock
palinux
test1

Jeśli jesteś adminem któregokolwiek z tych projektów, podrzuć mi pocztą elektroniczną klucz ssh, a ja go z powrotem dodam.

Zostawienie dysku w spokoju przez noc ,,naprawiło go'' na tyle, że mogę wydobyć niektóre dane. Minie jeszcze parę godzin, zanim się dowiem ile, ale udało mi się wydobyć wszystkie klucze ssh, opisy projektów i ich statystyki. Pracuję teraz nad prawdziwymi danymi, bo są drzewa, takie jak ppc, których nie można znowu znaleźć.

Dysk ma bad bloki, jeśli się ich dotknie, to zaczyna powtarzać i próbować la la land, zatem nie będę wiedział, które dane są złe, zanim nie trafię w badbloki.

Ewidentnie nie przeczytałeś wątku. Zarówno w kontekście BitKeepera, jak i w kontekście normalnych danych, zobaczyłbyś, że mamy kopie zapasowe, po prostu mamy kopie, których poprawność możemy weryfikować. Repozytoria na bkbits.net są automatycznie mirrorowane po przyjściu każdego zdarzenia. Było parę repozytoriów ppc, dla których to się nie działo i cały czas próbujemy dociec dlaczego, rzeczy takie jak klucze .ssh nie były też archiwizoane; naprawiamy to przez umieszczenie tej informacji w repozytorium BK, będziemy więc je mirrorować automatycznie jak wszystko inne.

Nie wiem czemu grasz mi na nerwach, to nie jest produktywne i po prostu niegrzeczne po tym, jak spędziłem dwa dni na składaniu wszystkiego razem wraz z deweloperami jądra. Co dokładnie miałeś nadzieję osiągnąć?

świadomość z twojej strony, że są ludzie, którzy prezentują ci prawidłowe argumenty, nawet jeśli się z nimi nie zgadzasz. Przeczyałem pierwsze listy tego wątku, do miejsca, w którym zniżyłeś się do tekstu ,,nasza aplikacja robi wszystkie możliwe sprawdzenia integralności w celu sprawdzenia poprawności danych. Nawet jeśli coś się zepsuje, będziemy wszystko wiedzieli. To dlatego jesteśmy lepsi niż reszta'' i tym argumentem zastrzeliłeś wszystkich, którzy prezentowali ci inne rozwiązania. Cóż, w tym przypadku, oczywiście wiesz, że dane nie są poprawne (bo dysk umarł, tu Ci współćzuję, z moich ośmiu dysków IBM DTLA, trzy też zdechły i boję się, że pięć pozostałych też padnie), a żadne twoje sprawdzenia nie pomogą tam, gdzie pomoże kilka aktualnych kopii zapasowych.

Jestem naprawdę też trochę rozczarowany, że ty, z całym swoim profesjonalizmem, który błyszczy na tej liście w każdej twojej wiadomości, uruchamiasz taką pokazową część swojego przedsięwzięcia, jaką jest bkbits.net na dyskach IDE bez RAID. I bez clustra w razie wypadku.

Myślę, że wróciliśmy do żywych. Wszystko od ssh jest z powrotem dostępne. Zajrzyjcie na www.bkbits.net, wasze rzeczy powinny tam być.

Dajcie mi znać, jeśli waszemu projektowi czegoś brakuje, wiem o drzewie ppc, mamy te dane, to będzie następne. Ale oprócz tego, wszystko powinno być z powrotem na miejscu, dajcie mi znać jeśli to nieprawda.

Przez ostanie 5+ dni VGER nie mogło połaczyć się z jakimkolwiek serwerem MX w twojej domenie. Dlaczego? Nie mam pojęcia. Komunikat diagnostyczny brzmi: ,,przekroczony czas połączenia''.

Ktoś coś tam zrobił ze ścianą ogniową i teraz odrzuca ona połączenia z TCP/ECN ?

Użyj narzędzia http://vger.kernel.org/mxverify.html by zobaczyć jak to działa.

Zobacz Documentation/filesystems/porting

BKL zostało przesunięte wewnątrz paru metod, zatem kod systemu plików sam w sobie ma to samo blokowanie jak kiedyś (to znaczy kod, który był pod BKL jest dalej pod nią). Jeśli twój kod nie potrzebuje BKL - możesz śmiało zmniejszyć ten obszar, ale pamiętaj, że zwykle było to w czasie BKL.

Nie _dodałem_ BKL - ani w devfs, ani nigdzie indziej. lock_kernel() to granica chronionego obszaru i wszystko co się zdarzyło to to, że ten obszar został skurczony, więc jego granice są wewnątrz metod, zamiast być wokół wywołania.

Powtórzę, dalsze kurczenie tego regionu zależy od opiekunów systemów plików.

Tydzień temu wysłałem to: http://groups.google.com/groups?selm=linux.kernel.3CA20C9B.20309%40us.ibm.com

Nikt nie miał nic do powiedzenia na ten temat, zatem przesyłam łatę. Przesuwa ona disassociate_ctty(1) do góry, i zwalnia BKl gdy pójdzie w dół. Czy to jest rozsądne, czy może niektóre z funkcji exit_*() ciągle potrzebują tty?

Łata ta stukrotnie zmniejsza czas trwania BKL w do_exit(). Ten czas to było około 200us, teraz jest to około 1.5us. Liczby te jednak są wzięte z maszynki Martin Bligha z NUMA-Q, więc reprezentują one naprawdę najmniej korzystny scenariusz.

Wolałbym, by BKL zostały po prostu przesunięte do funkcji, które ich potrzebują i w ten sposób usunięte z do_exit().

To jest szczególnie prawdziwe, bo nie wiem czy sem_exit() naprawdę wymaga jeszcze BKL - jeśli nie, możemy ją stamtąd usunąć (w tym miejscu jest to zatem problem lokalnej implementacji, bardziej niż rzecz, która dotyczy wielu modułów).

Sprawa z disassociate_tty jest jasna z podobnego powodu - i tak mamy zamiar kiedyś naprawić warstwę tty, zróbmy więc szczegóły związane z BKL wewnętrzną sprawą warstwy tty.