Kernel Traffic #142 For 19 Nov 2001

Gdy /usr/sbin/ntpd synchronizuje zegar jądra Linuksa (lub systemowy), wykorzystując Network Time Protocol, czas jądra jest ustawiany z dokładnością do kilku milisekund. Linux nastawia RTC (albo sprzętowy zegar, albo zegar CMOS-u) na ten czas, w przybliżeniu, co 11 minut. Typowe RTC mają niedokładność nie większą niż 10 s na dzieñ, więc rebutowanie powoduje jedynie milisekundowe błędy.

W tej chwili Linux nie zapisuje tych jedenastominutowych aktualizacji do żadnego pliku. Programy do obsługi zegara (takie, jak hwclock) nie mogą poprawić błędów RTC przy butowaniu, nie wiedząc, kiedy RTC był ostatnio nastawiony. Jeśli usługa NTP jest dostępna po dłuższym czasie wyłączenia, ntpd może poprawnie ustawić czas. Gorzej, gdy po dłuższym czasie spoczynku, ntpd odmówi współpracy lub nawet dostosuje się do złej strefy czasowej. Obejścia tego problemu są niezręczne.

Popatrzcie na moją malutką łatkę na linux/arch/i386/kernel/time.c, która dodaje KERN_NOTICE, co 11 minut, dla każdej aktualizacji RTC. Na razie mam jedynie wersję na architekturę i386. Skrypt umie przeszukać logi pod kątem ostatniego wystąpienia wpisu o aktualizacji RTC i zaktualizować /etc/adjtime. W takim wypadku hwclock może skorygować RTC o odpowiednią wartość i nastawić zegar jądra.

Załatałem jądra 2.2.19 i 2.4.12, które następnie skompilowałem, zainstalowałem i uruchomiłem na komputerach z procesorami Pentium MMX i AMD K6-III. Gdy zegar jądra był synchronizowany, linia ,,...: Real Time Clock set at xxx s'', gdzie ,,xxx'' to aktualny czas systemowy, pojawiała się w logu jądra co 661 sekund. Komunikaty znikały, gdy zegar był rozsynchronizowany. Ntpd co 661 sekund dodaje 4 linie do logów, więc wzrost rozmiaru logu jest niewielki, bądź żaden -- w wypadku, gdy użytkownik nie korzysta z ntpd. Łata dodała 11 bajtów do rozmiarów skompresowanego jądra.

PYTANIE: Co ma większy wpływ na dokładność czasu w RTC: regularne aktualizacje, czy przechowywanie przesunięcia?

ODPOWIEDŹ:

Kod jądra Linuksa z arch/i386/kernel/time.c, który dokonuje aktualizacji co 11 minut, ma tolerację w ustawianiu RTC +-0.005 s. Źródła adjtimex sugerują błąd przy odczycie rzędu +-0.000025 s.

Dokładne przechowywanie czasu w RTC wymaga także dokładnej wartości średniego błędu zegara przy normalnym wykorzystaniu. Mierzenie go wymaga pomiarów przez długi okres, powiedzmy miesiąc, bez synchronizacji.

Logowanie przesunięcia jest dokładniejsze przy odczycie i pozwala na dokładniejszy pomiar, niż aktualizacje co 11 minut.

KONIEC ODPOWIEDZI.

Dokładność RTC pozwala na opcjonalizajcę jedenastominutowych aktualizacji.

Inne powody, aby zopcjonalizować jedenastominutowe aktualizacje, zasugerowane przez różne osoby:

1. Jądro nie powinno określać polityki systemu operacyjnego;
2. Upraszcza programowanie /dev/rtc;
3. Poprawia wydajność /dev/rtc;
4. Nieco zmiejsza rozmiar jądra;
5. Nieco przyspiesza timer_interrupt;
6. Ułatwia wykorzystanie narzędzi takich, jak hwclock.

Pavel, zgadzam się z Tobą. Zakomentowanie kodu dokonującego aktualizacji co 11 minut jest lepszym wyjściem. :)

Jest to poprawka do problemu z algorytmem szeregowania na UP i SMP, który ostatnio opisał mi Alan, odnośnie kłopotów z ,,planowaniem procesów intensywnie zużywającym moc CPU''. Sęk tkwi w tym, że jeśli istnieje kilka procesów intesywnie wykorzystujących CPU, obok których funkcjonują inne zadania do planowania, takie jak interaktywna praca, lub aplikacje intensywnie wykorzystujące sieć, wtedy Linuksowy algorytm szeregowania źle wykonuje zadanie kojarzenia procesów z pamięciami podręcznymi procesora. Takie zachowanie algorytmu szeregującego jest wspólne dla większości ważnych aplikacji: serwerów baz danych, serwerów WWW, zadañ wymagających skomplikowanych obliczeñ matematycznych, oraz innych aplikacji.

Jeżeli występują CPU-żerne procesy A, B i C; oraz zadanie X, intensywnie korzystające z planowania, wtedy w czystych jądrach 2.4 otrzymujemy szeregowanie, działające w następujący sposób:

    A X A X A ... [impuls zegarowy]
    B X B X B ... [impuls zegarowy]
    C X C X C ... [impuls zegarowy]

czyli przęłączamy się między CPU-żernymi (i prawdopodobnie korzystającymi intensywnie z cache'u) procesami po każdym impulsie zegarowym. Impuls zegarowy może trwać 10 ms lub mniej, zależnie od wartości HZ.

Zamierzona długość okresu czasu dla takiego procesu powinna zależeć od jego priorytetu -- dla typowych CPU-żernych procesów jest to 100 ms. Jednak w powyższym przypadku, efektywny czas dla takiego CPU/cache-żernego procesu wynosi 10 ms lub mniej, co może spowodować zaśmiecanie pamięci podręcznej, jeżeli działający zestaw A, B i C jest większy niż rozmiar pamięci cache procesora, ale obciążenie generowane przez pojedynczy proces mieści się w tej pamięci. Ponowne zapełnienie obszernej pamięci podręcznej procesora może zająć wiele milisekund (przy procesorze Xeon z 2MB cache ,,on-die'', zabiera to ponad 10 ms), więc rezultat może być istotny.

Poprawnym zachowaniem byłoby:

    A X A X A ... [10 impulsów zegarowych]
    B X B X B ... [10 impulsów zegarowych]
    C X C X C ... [10 impulsów zegarowych]

Takie coś dzieje się tak naprawdę wtedy, gdy czynność szeregowania procesu 'X' nie ma miejsca.

Rozwiązanie: wprowadziłem nowe pole current->timer_ticks (nie będące w ,,gorącym schowku'' algorytmu szeregującego, ani nie powodujące żadnych narzutów szeregowania), które zlicza ilość impulsów zegarowych zarejestrowanych przez dany proces. Jeżeli liczba ta będzie równa liczbie dostępnych okresów czasu, wtedy przerwanie zegara zaznacza proces do przeszeregowania, czyści ->counter i ->timer_ticks. Owe 'impulsy zegarowe' muszą być prawidłowo zarządzane przez fork() i exit(); w kilku miejscach, w których modyfikowany jest ->counter, należy też zadbać o timer_ticks, ale poza tym łata wprowadza niewielkie zmiany.

Wpływ na semantykę szeregowania: powoduje to, że 'pożeracze' CPU są bardziej związane z CPU, na którym były uruchomione i będą ,,przysmażać'' je intensywniej -- bez oddawania im większej ilości czasu procesora niż przy standardowym szeregowaniu. Zmiana ta nie wpływa na zadania interaktywne, gdyż i tak zwiększają one swój ->counter powyżej tych 'pożeraczy'. Może to powodować mniejszą 'interaktywność' przy 'pożeraczach', ale jest to zamierzony efekt.

Wpływ na wydajność: pole to nigdy nie jest używane w 'gorącej ścieżce'. Jest używane tylko przez przerwanie zegara niewielkiej częstotliwości, oraz przez ścieżkę fork()/exit(), które mogą pobierać dodatkowy argument bez żadnego widocznego, negatywnego wpływu. Oprócz tego, należało poprawić kilka marginalnych przypadków, które zmieniały ->counter: kod OOM i zadania RR RT.

Wyniki wydajności: w przypadkach, które testowałem, zdaje się to pracować bez zarzutu, a zmiana ma efekt powinowactwa pamięci podręcznej, którego oczekiwaliśmy. Zmierzyłem czasy wykonania 'make -j bzImage' na maszynie z 8 procesorami Xeon z 2MB cache'u, taktowanymi zegarem 700 MHz (maszyna, której naprawdę trudno zaśmiecić cache). Oto czasy 6 kolejnych wykonañ make -j, z zaaplikowaną łatą, oraz bez niej (aby uniknąć układu stron cache oraz innych efektów, system pracuje ze zmodyfikowaną, lecz funkcjonalnie równoważną wersją łaty, która pozwala na przełączanie między starym i nowym zachowaniem algorytmu szeregującego podczas pracy).

standardowe szeregowanie:

  real    1m1.817s
  real    1m1.871s
  real    1m1.993s
  real    1m2.015s
  real    1m2.049s
  real    1m2.077s

z zaaplikowaną łatą:

  real    1m0.177s
  real    1m0.313s
  real    1m0.331s
  real    1m0.349s
  real    1m0.462s
  real    1m0.792s

jak widać, standardowy algorytm szeregujący wykonuje zadanie w 62.0 sekundy, nowy -- w 60.3 sekundy; 3% poprawa -- całkiem nieźle, biorąc pod uwagę fakt, iż kompilacja dokonuje się w 99% w przestrzeni użytkownika, a także to, że podczas kompilowania nie było żadnej działalności 'interaktywnej'.

- aby dokonać dalszych pomiarów efektów łaty, zmieniłem HZ do 1024 na jednoprocesorowej maszynie z Xeonem taktowanym 700 MHz i 2MB pamięci cache, co poprawiło czasy kompilacji jądra przez 'make -j' o 4%.

- Równoległe kompilowanie tylko drivers/block/floppy.c (co jest operacją intesywnie używającą cache'u), ze stałym obciążeniem sieci, przy pojedyñczym procesie Apache'a w tle, pokazuje 7% poprawę.

Oto wyniki, których oczekiwaliśmy: z mniejszymi przedziałami czasu, efekt zaśmiecania cache'u jest bardziej widoczny.

(Notka: użyłem 'make -j' tylko do stworzenia dobrze znanego obciążenia roboczego, które zostawia duże ślady w cache'u. Nie polecam używania 'make -j' na maszynach jednoprocesorowych, gdyż nie ma to zbyt dużego sensu.)

(byłoby miło, gdyby ludzie, którzy doszukują się problemów skalowalności w ich obciążeniach, mogli wykonać dalsze testy tej łaty, czy też zweryfikować wyniki obecnych.)

Jest to łata na jądro 2.4.15-pre1, uruchamia się i pracuje poprawnie zarówno na systemach jedno-, jak i wieloprocesorowych.

Jeśli chodzi o pomysł, obie łaty są zgodne.

O tym, czy są zgodne technicznie, musi zadecydować ktoś inny.

Łata Ingo w rezultacie obniża ilość jiffies pobieranych przez algorytm szeregujący w ciągu sekundy (powoduje, iż każde zadanie używa kilku jiffies).

Łata Davide'a może używać domyślnego szeregowania (a nawet tego zmodyfikowanego przez Ingo) w obrębie jednego procesora, używając dodatkowej warstwy szeregowania między poszczególnymi procesorami.

Myślę, że zwyciężają obydwa rozwiązania. Łata Davide'a pilnuje, aby zadanie nie było zbyt często przełączane pomiędzy procesorami, natomiast łata Ingo powoduje, iż każde zadanie na każdym CPU używa najkorzystniejszego rozmiaru cache'u.

Pozostaje do udowodnienia, czy zgrubne podejście do planowania (Ingo), tak naprawdę pomoże przy przeglądaniu właściwoście cache'u... Gdy zadanie zajmuje dłuższy okres czasu, pozostałe mogą w tym czasie zostać zapisane na dysk. Kiedy następne zadanie wraca, musi ponownie wypełnić cache. Tak samo jest dla następnego, itd...

Wygląda na to, że przy zapisach dużych ilości danych na partycje NFS, gdzie zdalna koñcówka jest wolniejsza niż lokalna, lokalny komputer zdaje się rozpoczynać intensywne swapowanie. Sądzę, że jest to spowodowane faktem, iż może on czytać dużo szybciej, niż jest w stanie zapisać.

Widzę również, nawet przy wysokich wartościach dopuszczalnego opóźnienia, przekroczenie czasu oczekiwania NFS-u i spowowdowane nim komunikaty ,,I/O error'' przy kopiowaniu, gdy jest zamontowany z opcją ,,soft''. Opcja ,,hard'' działa dobrze, ale nie chciałem jej używać w tym przypadku.

prawdziwym powodem, dla którego kod zapisujący na NFS powoduje swapowanie, jest to, iż warstwa VM tak naprawdę nie rozumie pojęcia stron z opóźnionym zapisem.

Warstwa VM ma jeden, wyraźnie określony, specjalny przypadek: wie o całej magii w ,,page->buffers'' i potrafi poprawnie obsługiwać opóźniony zapis na urządzeniach blokowych. Ale każdy, niezorienowany buforowo system plików jest ,,niewidzialny'' dla warstwy VM i musi wykorzystywać inne sztuczki, aby VM zignorowała jego strony.

W przypadku NFS zwiększany jest licznik stron i mamy prywatne, nie-widoczne-dla-VM struktury danych dla opóźnionego zapisu. To mocuje stronę w pamięci, ale w tym samym czasie, ponieważ VM tego nie rozumie, VM będzie myślała, że strona jest mapowana w przestrzeni użytkownika, czy jeszcze gdzieś indziej i nie będzie wiedziała, jak rozpocząć zapis.

Szczerze mówiąc, nie bardzo wiem, jak to poprawnie rozwiązać. Uczynienie z ,,page->buffers'' ogólnej rzeczy (,,void *''), oraz uczynienie z logiki zapisu buforów operacji poza przestrzenią adresową, powinno być rzeczą właściwą na duższą metę.

Zwracasz uwagę jedynie na opóźniony zapis. Ale nie zapominaj, że odczyt & odczyt z wyprzedzeniem również mogą pożreć pamięć, jeśli ktoś zapomni wywołać lock_page() (normalna rzecz przy montowaniu ,,hard,intr'').

Zauważysz, że w aktualizacjach NFS, które jakiś czas temu Ci wysłałem, jest nowa funkcja 'nfs_try_to_free_pages()', która udostępnia dość ogólny sposób na zwalnianie zasobów pamięci, wykorzystywanych przez NFS. W chwili obecnej, głównym jej celem jest upewnienie się, że nie przekraczamy granicy 256 żądañ na montowanie.

Mój (cały czas w jakiś sposób istotny) plan polega na rozszerzeniu tego interfejsu, gdzieś w trakcie 2.5.x tak, aby umożliwić VM kontrolę oraz ograniczenie zużycia pamięci przez klienta NFS -- wykonując żądania odczytu i zapisu, jeśli to konieczne. IMHO, system plików często będzie bardziej wydajny przy czyszczeniu stron, gdy zostawimy jemu samemu strategię wyboru, zamiast zagłębiać się w mikrozarządzanie VM, którą dokładnie stronę wyrzucić na początku. Na przykład przy NFSv3, jest zazwyczaj dużym zyskiem wysłanie COMMIT przez każdym innym wywołaniem, ponieważ może to zwolnić potencjalnie całe mnóstwo stron.

Dla wszystkich, którzy jeszcze tego nie widzieli, Moshe Bar na BYTE.com powtórzył swoje testy porównawcze Linuksa 2.4 i FreeBSD, używając teraz 2.4.13:

http://www.byte.com/documents/s=1794/byt20011107s0001/1112_moshe.html

W trakcie pierwszych testów, wykonywanych przy użyciu nowowypuszczonego 2.4.0, Linuks został istotnie pobity przez FreeBSD i wykazał wszystkie możliwe problemy z interaktywnością przy dużym obciążeniu, głównie z powodu VM i tego typu spraw.

Ale teraz, w nowych wersjach, naprawdę zaczynamy znów go doganiać. Nowa VM i miliony innych poprawek od czasu 2.4.0 spowodowały różnicę. FreeBSD jest systemem robiącym wrażenie i wartościowym konkurentem, z wyróżniającym się dziedzictwem - świetnie jest, że Linux depcze mu po piętach.

Składam zatem gratulacje wszystkim deweloperom jądra - 2.4.x w koñcu się udało i miesiące ciężkiej pracy dały w efekcie stabilne, efektywne i wydajne jądro. Czekam na szybkie uruchomienie 2.4.15, mieszanki Linus / Alan, a może nawet na 2.5.x - razem z podążającym ku nowym poziomom Linuksem.

Umm... Dokładnie napisał, że to jest Bardzo Zły Pomysł dla systemów produkcyjnych. Po prostu chciał zmierzyć raczej ogólny przerób, niż opóźnienia dysku (a to jest właśnie wąskim gardłem przy włączonym fsync()).

To test, cieszcie się! ;)