Kernel Traffic #135 For 1 Oct 2001

Możesz przeprowadzić kilka testów zaprojektowanych specjalnie do testowania opóźnieñ, takich jak testy audio. Jeden z nich jest dostępny pod adresem http://www.gardena.net/benno/linux/latencytest-0.42.tar.gz

Oczywiście wielozadaniowy test WE/WY jest użyteczny, sam używałem dbench w przeszłości ftp://samba.org/pub/tridge/dbench/) (z 16 procesami, czy coś koło tego), ale dowiedziałem się, że powinienem używać bonnie.

Możesz także mierzyć czas wykonania poleceñ przy pomocy time. `time make dep clean bzImage' jest oczywiście najlepszym kandydatem :)

W systemach UP włączenie wywłaszczanie pomaga we wszystkich wymienionych wyżej przypadkach (ostatni artykuł o wywłaszczaniu na linuxdevices pokazuje 30-tokrotny spadek opóźnieñ). Nigel i ja testowaliśmy łatę dla wersji -16 przy użyciu dbencha z całkiem dobrym rezultatem. Zobacz http://kpreempt.sourceforge.net/ żeby dowiedzieć się więcej.

Po kilku dniach pracy uważam, że jestem gotów do opublikowania zmian w VM, których dokonałem.

Alternatywna VM będzie włączona do 2.4.10pre9aa1 (czy też po prostu do kolejnej wersji -aa) i będę ją rozwijał w gałęzi -aa. Nowa wersja oferuje:

1. stabilny kswapd, zapobiega używaniu przez kswapd 100% czasu pracy procesora (zostało to uzyskane przy pomocy architektury classzone, przu okazji poprawiłem trochę implementację w stosunku do łat do 2.3/4.4.0-test, teraz próbuję wszystko robić tak leniwie, jak to możliwe bez zapisywania w pagealloc/pagefreeing)
2. optymalną wydajność, zapobiega spowolnieniom po wielokrotnym wzroście obciążenia i zapobiega masowemu wyswapowaniu (dla baz danych nie używających O_DIRECT)
3. dostęp do swap+ram wirtualnej pamięci

W tej chwili jest to jeszcze łata dość eksperymentalna i będzie ulegać zmianom, ale ten email piszę właśnie na systemie z tą łatą i działa całkiem zacnie.

To nie jest jakiś brzydki hack, jakieś łatanie dziur, czy mały zbiór zmian. To jest całkowite przepisanie od postaw całego zarządzania pamięcią włączając w to odśmiecanie pamięci, listu lru, kswapd itp...

To jest zły kierunek pracy.

Na NuMA z łatą classzone wszystko nam się rozsypie. Mówilem to wcześciej, powtórzę i teraz.

Podejście stosowane w łatce classzone jest _złe_: w podejmowaniu ogólnych decyzji tam, gdzie nie ma żadnej ogólności.

Założę się, że poprawa wydajności pochodzi z innych rzeczy, a nie z samego classzone. Założę się również, że jeśli zaczniemoy robić te strefy klas, to BARDZO tego pożałujemy za kilka lat.

Ok, najważniejszą zmianą jest kontynuacja łączenia, tym razem z Andreą.

Cały czas nie podobają mi się niektóre zmiany w VM, ale włączenie zmian zaproponowanych przez Andreę zaowocowało w: (a) lepszej wydajności i (b) dużo przejrzystszej obsłudze nieaktywnych stron. Poza tym w drzewie 2.4.x wysoki priorytet ma stabliność, więc wszelkie moje uwagi możemy ponownie rozważyć w 2.5.x.

Zaaplikowana jest również łata z blkdev w cache strony, i to przypuszczalnie znacznie ułatwi wykonywanie ,,zrób bread() z cache strony'', co z kolei pozwoli uniknąć paskudnych synchornizacji, które mamy obecnie.

Ah, i jeszcze włączyłem poprawki Andrei z direct-IO.

[ Inne małe łatki Andrei zostały również włączone, aby ułatwić aplikowanie kolejnych uaktualnieñ. ]

Włączenie łaty Andrew Mortona na blokowanie konsoli także przypliża nas nieco do drzewa -ac...

Andrea,

Osobiście uważam, że jest zbyt późno, aby włączać twój kod do 2.4.x.

Nie mam nic przeciw kodowi jako takiemu ("stary" kod też miał błędy), ale tak poważna zmiana VM w tym momencie wydaje się być bardzo niebezpieczną, jeśli chcemu mieć stabilną obsługę VM.

Nie uważasz, że twój kod może wprowadzić kolejne zakłócenia stabilności?

Linus, proszę, jeśli chcesz włączyć kod Andrei, zrób to w 2.5.x, a nie w 2.4.x. (tak, spodziewam się, że na mnie teraz nawrzeszczysz :))

Bez wahania? Nie bardzo.

Poprawki z -ac nie są włączone do -linus PONIEWAŻ NIKT NIE PRZYSŁAŁ MI ODPOWIEDNICH ŁAT.

Alan pracuje nad tym dość intensywnie, ale jest faktem, że nie jest w stanie dostarczać mi łat synchronizacyjnych tak szybko, jak rośnie -ac. Dlatego poprosiłem ludzi, aby sami próbowali przenieść swoje kawałki kodu z -ac do -linux aby pomóc Alanowu. W ten sposób powstały inne części -pre11.

Drzewo aa istnieje już dość długo i jest podzielone na lepsze kawałki niż drzewo -ac, co czyni zmiany łatwieszymi do włączenia. Niewątpliwie gusta moje i Alana są często bliższe sobie niż moje i Andrei, co oznacza, że łączenie z drzewem -aa jest bardziej bolesne dla _mnie_ ;-)

Zabawne, że o tym wspominasz, bo właściwie to mam przebiegły plan, a Ty jesteś jego bezwiedną częścią.

A właściwie to mam nadzieję, że jesteś jego "wiedną" częścią, ponieważ to będzie Twój kod.

Weź swój kod "struct block_device", dodaj do niego "struct address_space", a gdy tylko inode urządzenia blokowego jest otwarty, spraw aby inode->i_mapping wskazywało na &bdev->b_data, i voila..

Otrzymujesz już poprawnie całe obliczenia referencyjne, a i tak jest to jedyne sensowne miejsce do zrobienia tego, nie zgodzisz się?

Miałem nadzieję, że poczujesz dreszczyk emocji. Zdaje się to bardzo dobrze pasować do Twojego powolnego alokowania..

Tak, możemy to zrobić w ten sposób (patrz niżej w wątku. Tak, w połączeniu z leniwym alokowaniem (oraz schematem podobnym do pipefs) może się to zmienić w niezły, _działający_ kod.

Ale teraz mamy

1. niesprawną łatę nałożoną na drzewo
2. łatę przetestowaną w nieznacznym stopniu, która być może (po zmodyfikowaniu, tak, aby została _zaaplikowana_ na -pre11) naprawi błędy. Znaczy się po przetestowaniu jej na tyle dokładnie, aby można było traktować ją jako kandydata do włączenia.

IMNSHO jest to jakby niezbyt idealna sytuacja. Rozmawiałem już z Andreą i kiedy powróci do żywych (nie, śpi sobie tylko) postaramy się zrobić coś użytecznego. Życie byłoby jednak dużo łatwiejsze, gdyby wspomniany wyżej przebiegły plan obejmował wysłanie poczty do uczestników (ja i Andrea) przed nałożeniem łaty na drzewo. No nic...

To jest właśnie to co lubię w łacie page-cache bdev. Ma dużo całkiem brzydkich narośli, ale wszystkie wydają się możliwe do naprawienia poprzez uporządkowanie _innych_ rzeczy, w którym to miejscu pozostaną tylko dobre części.

Zgadzam się, że czas może pozostawiać trochę do życzenia. Jednak dyskutowaliśmy o naprawianiu spójności pagecache-bdev w odniesieniu do dostępu do systemu plików z normalnym buforem pamięci podręcznej jakiś tydzieñ temu, i w rzeczywistości wygląda na to, że nikt nie zabrał się za prace nad tym - ponieważ każdy myślał, że trzeba zrobić wszystko naraz.

Ja tak nie myślę. Jestem zadowolony z częściowych uaktualnieñ z brzydkimi naroślami, jeżeli tylko oznacza to, że można dojść do etapu koñcowego _bez_ konieczności rozwiązywania wszystkich problemów jednocześnie.

Teraz mamy więc dwa _mniejsze_ uaktualnienia, które rozwiążą dwie inne sprawy i usuną całą brzydotę z oryginalnego uaktualnienia.

Prawdziwe pytanie to dlaczego nie otworzymy serii 2,5 i na początek nie naprawimy VM? Zostawmy kernel na etapie 2.4.10-pre10, być może użyjmy kodu -ac VM (który rozszedł się z głównym drzewem), i pozostawmy ludzi, (Alana, Bena, Marcello, i innych) którzy chcą z nim majstrować w małych kawałkach, a w 2.5 róbmy drastyczne rzeczy.

Wyjaśnij, że w chwili obecnej 2.5 służy nadal TYLKO do pracy nad VM i usuwania innych błędów, a nie jest JESZCZE długo oczekiwanym przerobieniem 2.5. Jeżeli okaże się, że usuwanie błędów w VM idzie szybko, mogą one być z powrotem portowane na 2.4. Jeżeli zajmie to więcej czasu niż oczekiwano, będziesz mógł otworzyć 2.5 do ogólnego rozwijania.

Z odpowiednim ,,zarządzaniem'' nie będzie się to znacznie różniło od bieżącej sytuacji, z tym tylko wyjątkiem, że ludzie nie będą się wściekali o wprowadzanie tak wielkich zmian do 2.4. Myślę, że to Twoja podświadomość mówi Ci, że tak naprawdę to chciałeś rozpocząć 2.5 miesiąc temu.

Słuchaj, problem jest w tym, że Linus zachowuje się jak dupek, wprowadzając sprzeczne pomysły do zarówno VM jak i VFS, bez uprzedniego powiadamiania kogokolwiek, a potem zwala na innych.

Popatrz tylko jak próbuje zmusić Al Viro do wprowadzenia jego pomysłów wczoraj, ponieważ znowu rozwalił kod...

Jeżeli chcesz mieć stabilne jądro, używaj jądra Alana.

Rik, gdybyś czasem tego nie zauważył, potrafię mówić za siebie. Spędziłem dziesięć lat migając się przed poborem; jeżeli zdecyduje się gdzieś zaciągnąć, stanie się to za _moją_ decyzją na _moich_ warunkach. Kiedy zdecyduję, że jestem zmuszany do czegoś, czego nie akceptuję - dowiesz się o tym z postu podającego URL do nowej gałęzi odchodzącej z drzewa głównego.

FWIW, Wcale mnie nie ekscytuje nowa łata Andrei, można ją jednak naprawić. Nie ekscytuje mnie też wcale cała sytuacja związana z VM - wszystkie jej strony. Naprawdę przypuszczam, że potrzeba w tym miejscu ograniczonego rozgałęzienia w wielu kierunkach, tak, abyście mogli przestać przestać się obrażać. Ja nie biorę udziału waszej radosnej 5-cio kierunkowej zjebce - sami między sobą uprzątnijcie ten bajzel.

Jeszcze raz, jeżeli zdecyduje, że sytuacja jest dla mnie nie do zaakceptowania - po prostu rozwidlę drzewo. _Nie_ podoba mi się zaciąganie mnie na czyjekolwiek święte wojny, więc nie baw się w politykę w pobliżu mojej osoby - chyba, że naprawdę chcesz _znacznie_ podskoczyć w mojej osobistej Shitliście (kilka pozycji poniżej .ru DoD).

Przepisuję wrapfs z projektu fist i jest on aktualnie w fazie odpluskwiania, w sumie to jest gotowy do testów eksperymentalnych.

Pomysł pochodzi z FiST, wieżowego systemu plików. Ale właściciel tego projektu, Erez, chyba porzucił utrzymywanie tego projektu. W momencie, w którym dostałem ten kod, był pełen błędów, prawie nie do użytku, było wiele problemów związanych z odwołaniami do pamięci. Odpluskwiałem go dobrą chwilę. Teraz jest użyteczny, gdy jest używany jako wrapper do sstemu plików. Jest użyteczny w chrootowanym środowisku, ale nie są dostępne twarde linki. Montuje on katalog w innym katalogu, powyżej wszystkich systemów plików. Chciałbym zostać opiekunem tego systemu plików, bo pomysł na FiST jest dobrym pomysłem. Pozwala używać bazowego wrapfs jako wzorca, można na nim w krótkim czasie dorobić szyfrowanie czy inne operacje. Jeśli któryś z maintainterów systemu plików w jądrze jest zainteresowany to proszę o kontakt.. Chciałbym uzyskać pomoc w dokoñczeniu mojej pracy nad opluskwianiem. Wynik będzie dostępny na GPL. Spakuję to także przy pomocy fistgen jako narzędziem pozwalającym rozwijać system plików.

Staram się ostatnio rozeznać w kwestii implementacji nowego systemu plików na użytek mojej pracy dyplomowej. Traktuje ona o projektowaniu i implementacji sieciowego systemu plików, w domyśle bezpiecznego. Dla zainteresowanych, na moich stronach, jest krótkie wprowadzenie o tym dlaczego i po co (zwróćcie uwagę na sekcję o bezpiecznym systemie plików w Internecie):

http://www.linuxnetworks.de/security/index.html

Zacząłem prace nad łatą dla /proc/sys/kernel/tainted oraz związanymi z tym modutils oraz zmianami w ksymoops. insmod modułów nie będących na GPL wykonuje operację or na /proc/sys/kernel/tainted i 1, insmod -f wykonuje taką operację z 2.

Co jednak zrobić z modułami bez licencji? Skarżyć się i piętnować czy po cichu ignorować? Wiele modułów w -ac14 nie ma MODULE_LICENSE, być może dlatego, że nie ma MODULE_AUTHOR. Moim zdaniem domyślnie powinno się je piętnować, nie przejmując się tym, że to spowoduje wiele pytañ na l-k zadawanych przez nowicjuszy.

Łatka dodająca ext3 dla linuka 2.4.10 jest dostępna pod adresem

http://www.uow.edu.au/~andrewm/linux/ext3/

Ta łatka jest *trochę testowana* - znaczy butuje się i robi różne rzeczy. Zmiany w ext3 są małe, ale jądro, na które jest nakładana, bardzo się zmieniło ostatnimi czasy. Jeśli jesteście ostrożni, to poczekajcie jeszcze parę dni.

Łatka o której mowa ma w sobie jeszcze kod śledzący bufory. Wkrótce zostanie to podzielone na oddzielne łaty, tak żeby ext3 nadawało się do włączenia do głównych wersji jądra.

Changelog:

• Naprawienie oopsa, który mógł wystąpić w trakcie odmontowywania. Mogło to zostać włączone przez wcześniejszy błąd.
• Włączenie łaty autorstwa Teda, zawierającej heurystyki przyspieszające dostęp do katalogów.
• Usunięcie abort_write() address_space_operation przez zapewnienie, że każde wołanie prepare_write() zawsze woła też commit_write().
• Kilka zmian dopasowujących do nowej pamięci wirtualnej w 2.4.10 i zmiany obsługi buforów.

Jeśli to przejdzie, wszyscy ludzie zajmujący się bezpieczeñstwem komputerowym moga być aresztowani i wsadzeni do więzienia. Dodatkowo, ludzie tacy jak Kevin Mitnick mogą być aresztowani z powrotem, chociaż już odbyli karę za swoje przestępstwo (podwójne zagrożenie? (ang. double jeopardy?)).

http://www.securityfocus.com/news/257

"WEP crack" też będzie interesująco śledzić.

Teoretycznie, w przypadku stosowania się nowego przepisu, każda osoba, której komputer był zarażony przez nimda/codered może być aresztowany dożywotnio -- nowe prawo nic nie mówi o intencjach. Zatem mielibyśmy parę milionów użytkowników Microsoft Windows z wyrokami dożywocia...

Kiedy ludzie rozbijają samoloty o budynki i tysiącami zabijają ludzi, przepisy o hackingu powinny być twarde. Stany Zjednoczone odcięły dostęp internetowy z Cypru i paru innych miejsc i zauważyłem zmiejszenie liczby prób hakowania moich serwerów -- DOBRZE!.

Maureen O'Gara w Client Server News jest w NY, i z tego co opisuje, całe miasto jest w strasznym stanie. Chciałbym powiedzieć wszystkim naszym przyjaciołom w Nowym Jorku, że Utah Native American Church wysłał Jamesa Mooney'a do Nowego Jorku, aby poprowadził ceremonię za ofiary i ich rodziny. Biuro burmistrza dało nam zgodę na przeprowadzenie tam naszej ceremonii dla tych ludzi, nie musimy się obawiać interwencji policji.

Dostał wystarczająco dużo peyote, żeby obdzielić nim pół miasta. Każdy mieszkaniec Nowego Jorku, który potrzebuje ukojenia i jest członkiem linuksowej ,,rodziny'' będzie mile widziany na tych ceremoniach. Ludzie, którzy przeszli przez to przerażające doświadczenie potrzebują posiedzieć w wigwamie i uciec gdzie indziej na parę dni z uświęconym lekarstwem.

Ludzie z Nowego Jorku, którzy chcą wziąć udział w tych ceremoniach mogą zadzwonić pod 212-755-0968 lub 212-929-9396, żeby dowiedzieć się gdzie i kiedy się odbędą. Do tej pory ugościliśmy na nich tysiące ofiar. Wszyscy są mile widziani, wraz z rodzinami. Przepisy stanu Nowy Jork pozwalają używać peyote w celach religijnych nawet ludziom nie będącym Indianami, inaczej niż w Utah. Powiedzcie naszym braciom, że otwieramy drzwi dla tych mieszkañców Nowego Jorku, którzy potrzebują duchowego i emocjonalnego ukojenia.

Te ceremonie są **DARMOWE**. Utah NAC płaci rachunki.

W jaki sposób ostatnie akty przemocy różniły się tak znacznie od aktów, które zdarzają się na całym świecie, od, hm, zawsze? Czy chodzi o to, że ,,to się tu nie zdarza!"? To jest prezentacja spojrzenia na świat, w którym Stany Zjednoczone znajdują się w jego centrum.

Kiedy wydaje się, że na świecie panuje pokój, łatwo jest żądać swoich praw. Zaczynasz ich potrzebować wtedy gdy przychodzi wojna, a wtedy jest najtrudniej je uzyskać.

To była okropna zbrodnia, popełniona przez ludzi, którzy poświęcili swoje życie. To był błąd fizycznej ochrony; ale ogromne bazy danych nie utrudnią takich aktów ludziom, którzy zdecydują się poświęcić samych siebie.

Wpłyną jednak oni na zdolność populacji do nieposłuszeñstwa obywatelskiego i rebelii, na której ten i wiele innych krajów zostały zubdowane.

Wojna na świecie nie jest niczym nowym, po prostu przyzwyczailismy się to ignorować. I właśnie za to jesteśmy w wielu miejscach nienawidzeni i za to nami gardzą.

Nie podpiszę się pod zdaniem, że ,,Takim rzeczom należy zapobiegać za wszelką cenę''. Są takie ceny, których nie zapłacę i takie, które od razu pozbawią mnie zaufania wobec osób, które poproszą o ich zapłacenie.

Wiem, że tym, co napisałem nie przysporzę sobie przyjaciół, ale moja świadomość domagała się odpowiedzi na Twoje ślepe żądanie praw. Wolę świat, w którym moje dzieci będą mogły wybierać jak chcą żyć, nawet za cenę zmniejszenia 'bezpieczeñstwa'.

Wy-kurwa-starczy. Skoñczmy teraz ten wątek, nie należy on do tematu.

Jest wiele miejsc, gdzie można prowadzić konstruktywne dyskusje na ten temat, vger nie jest jednym z nich.

Nie zmuszajcie Mattiego ani mnie do dodawania kolejnego filtrowania słów na tej liście, tak by uniknąć tego tematu.