Kernel Traffic #138 For 22 Oct 2001

There were 651 different contributors. 326 posted more than once. 187 posted last week too.

1. Stan obsługi linmodemów w jądrze; nowa procedura obsługi zwrotnej plików /dev w przestrzeni użytkownika

Jeremy Elson z Sensoria Corporation niechcący rozwiązał wiele problemów z Winmodemami pod Linuksem. Ogłosił wersję 1.00 FUSD, wyjaśniając: " FUSD pozwala pisać demony działające w przestrzeni użytkownika, które mogą odpowiadać na odwołania do plików urządzeñ z /dev. Te pliki urządzeñ wyglądają i zachowują się z punktu widzenia procesów odwołujących się do nich dokładnie tak, jak inne pliki urządzeñ. Gdy moduł jądra FUSD dostaje odwołanie do pliku urządzenia, które jest zarządzane z przestrzeni użytkownika, przekopiowuje argumenty do wiadomości (włączając w to dane od wołającego, o ile jest taka potrzeba), blokuje wołającego i wysyła wiadomość do demona obsługującego urządzenie. Gdy demon generuje odpowiedź, proces przebiega w drugą stroną, a wołający zostaje odblokowany." Podał link do strony projektu FUSD.

Po zgłoszeniu kilku błędów, które pokazały, że FUSD został zbyt wcześnie przenumerowany na 1.00 (przypuszczalnie ze względu na sponsorów), Pavel Machek zasugerował wysłanie ogłoszenia na listę dyskusyjną o linmodemach dodając: "Zabicie tych wszystkich binarnych sterowników modemów w modułach jądra byłoby dobrą rzeczą... Hmm, i być może możemy zhakować API telefoniczne przez ltmodemy i z tym żyć. To byłoby dobre." Jeremy spytał: "Być może nie bardzo rozumiem jak działają linmodemy, nie na tyle aby domyślić się, jak można tu wpasować FUDS -- mówisz o użyciu linmodemów przez sterownik portu szeregowego? Jeśli tak, to wygląda to na dobre zastosowanie -- ale możemy mieć problem z binarnymi modułami, ponieważ format wiadomości przesyłanych pomiędzy przestrzenią użytkownika a jądrem wykorzystywany przez FUSD może się zmieniać w czasie. (Tak naprawdę to już się zmienił w stosunku do wersji 1.0, w odpowiedzi na maile, które dostałem w ciągu ostatnich kilku dni.)" Pavel potwierdził pomysł wykorzystywania portu szeregowego przez linmodemy: "Nom. A sterownik linmodemu obsługuje sygnały, dlatego jest duży i brzydki. I aż do teraz musiał być w jądrze. Z Twoimi łatami, takie sterowniki mogą być w przestrzeni użytkownika (tam gdzie ich miejsce!)" Ale on (i inni) nie był szczęśliwy z powodu możliwych zmian interfejsu. Jeremy wyjaśnił:

Interfejs FUSD-a użytkownik-jądro nie zmieni się radykalnie, ale co jakiś czas będziemy potrzebowali go zmienić, aby go dopasować do nowej funkcjonalności. Niektóre z takich zmian już się dokonują.

Fakt, że FUSD udostępnia półstabilny interfejs binarny do obsługiwania odwołañ do plików urządzeñ nie jest tak naprawdę celem FUSD, a jedynie efektem ubocznym. Tworzenie stabilnego interfejsu binarnergo dla sterowników urządzeñ jest celem UDI (tak sądzę). Celem FUSD jest stworzenie proxy dla odwołañ do przestrzeni użytkownika.

Gdzie indziej Eric W. Biederman poprosił o dokładniejsze wyjaśnienie, jak FUSD może być użyteczny dla linmodemów, na co Jeff Garzik odpowiedział:

Wydaje mi się, że najlepsze Linuksowe rozwiązanie dla winmodemów powinno składać się z trzech części: istniejącej części sprzętowej dla Lucenta (napisanej przez Pavla/Richarda/Jamiego/innych), kodu Rogiera Wolffa szeregowego sterownika dla przestrzeni użytkownika, oraz czegoś nazywanego ,,modemem'' przez byłych naukowców SGI(IIRC). Alan powiedział mi parę rzeczy o tym ostatnim. ,,Modem'' wyciąga do 14.4k i obsługuje kilka protokołów korekcji błędów, które pamiętamy jeszcze z czasów BBS-ów.

Trzeba po prostu kogoś, kto sklei te wszystkie kawałki... i będziesz miał sterownik winmodemu z odpowiednim kawałkiem w przestrzeni użytkownika i odpowiednim kawałkiem w przestrzeni jądra.

Pavel dodał: "Jeden ze studentów u mnie pracuje/pracował nad tym sklejeniem; to nie jest trywialne, ponieważ ,,modem'' jest zaśmiecony współprogramami." A Tim Jansen podał odnośnik do (dość starej) strony ,,modemów''. Do tego dodał: "To jest także istotne dla modemów USB. Ponieważ Intel naciska na producentów PC, aby przestali montowac porty szeregowe w 2002 roku, a modemy USB zgodne z Linuksem są rzadkością, będzie bardzo trudno znaleźć modemy zewnętrzne do nowych komputerów. Prawie każdy nowy modem USB jest oparty na chipsecie ST7554 albo Connexant HCF, a przynajmniej ST7554 nie ma kontrolera."

Morgan Collins zauważył, że jego jądro zostało ,,napiętnowane'' przez nie-wolne moduły, ponieważ moduł kompresji PPP jest rozpowszechniany na licensji BSD. Alan Cox i David Woodhouse powiedzieli, że to jest błąd. Jak wyjaśnił David: "Każdy kawałek kodu, który jest rozpowszechniany ze źródłami jądra ma odpowiednią, nawet jeśli nie jest w 100% zgodną, licencję i nie powinien piętnować jądra." Ale Keith Owens wtrącił: "Licencje nie wymienione w include/linux/module.h nie są zgodne z GPL." Podał listę tych licencji (z 2.4.11):

Licencja BSD jako taka nie była wymieniona na liście, więc (jak wywnioskował) kompresja PPP powinna napiętnować jądro. David uważał, że nieumieszczenie tam BSD-NAC (bez klauzuli o reklamowaniu) było głupie, a Alexander Viro sądził, że także LGPL powinno zostać tam wymienione. Keith stwierdził, że bieżąca lista została stworzona przez Alana Coksa, a Alan dodał:

Jeśli masz patent na kodzie BSD, nie możesz go rozpowszechniać na zasadach GPL, nie jest on też zgodny z GPL.

Problem stanowi to, że pod szyldem ,,BSD bez ogłaszania'' można rozpowszechniać każdy binarny moduł, którego autor nie dołącza źródeł albo źródła nigdy nie wyjdą od ich producenta.

Dla Davida to nie miało sensu; zauważył on, że patent może także ograniczyć dystrybucję kodu na GPL. Dodał: "W każdym razie, nie sądzę, aby postawa polityczna przeciw patentom była powodem piętnowania kodu jądra -- wydawało mi się, że miało to służyć celom zarządania." Kontynuował:

Ale jeśli nie zamierzamy ładować modułów dystrybuowanych na licencji BSD bez piętnowania jądra, nie powinniśmy żadnej części kodu dystrybuować na podstawie licencji BSD -- powinniśmy te części udostępnić jako ,,Podwójna BSD/GPL''.

Być może byłoby dobrze mieć wybór ,,Podwójna GPL/Inna'', aby objąć również inne kawałki objęte podwójnymi licencjami (jak JFFS2).

Niezidentyfikowany osobnik zasugerował, że moduły mogą po prostu kłamać na temat swoich licencji i obchodzić te wszystkie zabezpieczenia, ale Alan odpowiedział: "łamiąc przy okazji DMCA, za co grozi pięć lat więzienia. Jednakowoż prawda jest taka, że jeśli chcesz skłamać na temat licencjonowania, albo uruchomić modutils, które nie sprawdzają tego, nikt Cię nie powstrzyma. Głównym celem tego jest odfiltrowanie ludzi, którzy się nie znają. Ci którzy wiedzą, jak obejść te mechanizmy, i tak wiedzą, że nie ma sensu wysyłać informacji o błędach sterownika Nvidii na lk." Andreas Dilger zauważył, że tak naprawdę, to wystarczy usunąć informację o ,,napiętnowaniu'' z wyniku ksymoopsa i dodał: "Nie sądzę żebyśmy musieli się martwić problemem ,,GPL vs. BSD'' czy czymś takim, ale raczej problemem ,,czy źródła są dostępne'' jako kryterium do piętnowania modułu. Przecież, do diaska, użycie niektórych modułów z aktualnych źródeł jądra piętnuje jądro, co czyni całą tę operację nieprzydatną."

W pewnym momencie Andread Ferber zasugerował: "Co myślicie o dodaniu ,,BSD (włączone do jądra)'' jako jednej z możliwych ,,nienapiętnowanych MODULE_LICENSE()''?" Alanowi spodobał się pomysł, a Henning P. Schmiedehausen zaproponował ,,BSD (włączone do źródeł jądra)'', aby zaznaczyć dostępność źródeł. Pekka Pietikeinen dodał: "Albo nawet coś w stylu ,,BSD (niezmodyfikowane źródła dostępne ogólnie)'', co pozwoliłoby objąć nawet cudze sterowniki." Pod koniec dyskusji, ktoś zasugerował, aby po prostu użyć flagi wskazującej na dostępność źródeł, ale Alan Cox powiedział: "Dostępność, ale na jakich warunkach? NDA, które nie jest do zaakceptowania na innych zasadach? To nie jest takie proste, jak wygląda."

Dyskusja toczyła się jeszcze przez jakiś czas, ale nie podjęto ostatecznych decyzji.

W ciągu ostatniego tygodnia napisałem małą łatę dla 2.4.10-ac{9-10}, która wyraźnie poprawia wydajność VM. Pierwsze testy wskazują, że system działa o wiele płynniej w zasotosowaniach desktopowych i nie powoduje padów, chyba że zbiór, na którym operuje _naprawdę_ przekracza rozmiar RAM.

Wiele osób już prosiło o włączenie tej łaty do jądra -ac, ale wolałbym przeprowadzić jeszcze trochę testów na tej łacie zjadającej cache (ang. eatcache) i zatrzymującej pożeraczy (ang. stophog), zanim ją włączymy...

Łata implementuje następujące rzeczy:

całkowite obejście starzenia się stron dla nieużywanych obiektów w cache
zmniejszenie dystansu pomiędzy inactive_shortage i inactive_plenty, aby kswapd spędzał mniej czasu na mieszaniu losowymi stronami... w większości przypadków nie powinno to robić żadnej różnicy, ale w najgorszych przypadkach powinno zwiększyć odporność
wykonuje starzenie stron _przed_ testem zone_inactive_plenty(), tak więc stare bity referencyjne zostaną wyczyszczone [nie jest to duży narzut na cpu, ponieważ kod nie będzie uruchmiony, jeśli nie będziemy gdzieś mieli wolnych albo nieaktywnych niedoborów]
w page_alloc.c, przeszeregowanie ,,spowalniania'' jest silniejsze przez przesunięcie do try_to_free_pages(), co przy obciążeniu pamięci, owocuje w wołaniu try_to_free_pages() przez alokatory, gdy ilość pracy do wykonania nie jest jeszcze taka duża i gwarantuje im, że tuż po tym będą mogły się dostać do swoich nowych obszarów... statystyki pokazują, że pożeracze pamięci są znacznie bardziej spowolnione niż dobrze zachowujące się programy

Przetestujcie proszę tę łatę i powiedzcie Alanowi i mi, jak działa u Was i czy są obciążenia, gdy system działa lepiej bez tej łaty niż z nią...

Kilka osób się tym zainteresowało, a Andrea Arcangeli w pewnym momencie powiedział: "Później, jeśli będziecie mieli trochę czasu na testy, będę bardzo zainteresowany porównianiem z 2.4.12aa1." Trochę później John L. Makes powiedział:

Miałem możliwość przeprowadzenia kilku testów z nieoficjalnym jądrem 2.4.12 z SuSE, które, jak sądzę, jest oparte na 2.4.12aa1.

Użyłem:

ftp://ftp.suse.com/pub/people/mantel/next/RPM/k_i386-2.4.12-0.i386.rpm

Mam AMD K6-2-500 i odkryłem, że jądro na Pentium i domyślne jądro SuSE wiesza komputer jeśli w środku jest AMD K6-2. Nie byłem w stanie skompilować jądra ze źródeł używając:

ftp://ftp.suse.com/pub/people/mantel/next/linux-2.4.12.SuSE-0.tar.bz2

z powodu jakichś nieznanych technicznych problemów. Jednym z nich było to, że 'make xconfig' nie działało, a po 'make oldconfig' i innych make'ach do budowania jądra powodowało błąd przy kompilacji modułów. Obraz jądra był generowany poprawnie.

Ok, ale dość o tych pobocznych sprawach. Chodzi o to, że wyniki testów pokazują, iż jądro k_i386-2.4.12-0.i386.rpm spisuje się całkiem nieźle przy testach, które robiłem. Testy na tym jądrze zajęły około 20 minut. Zwłaszcza ostatni zestaw testowy jest interesujący, więc sugeruję, że fajnie by było skupić się na tym aby skrócić czas wykonywania tego zestawu, ale to może być niemożliwe ze względu na wąskie gardło powstające w systemie WE/WY.

Ten sam test przeprowadzony przy użyciu jądra 2.4.10-ac12, które ma zdaje się obie łaty Rika van Riela:

http://lwn.net/2001/1011/a/cache-reclaim.php3

http://lwn.net/2001/1011/a/smooth.php3

Wyniki nie były najlepsze. ,,Dokładnie'' taki sam test zajął trochę ponad 3 godziny.

Część testu, która zdaje się stwarzać problemy z 2.4.10-ac12 operuje na zbiorze 300MB. Na ten 300MB zbiór składa się kilka 60MB elementów (pomieszane pamięć systemowa, dzielona, cache i bufory) po wystartowaniu systemu. System do testów uzywa 256MB RAM i 256 MB pliku wymiany. Wygląda na to, że 2.4.10-ac12 koñczy z zaalokowanym nadamiarem (narzut??) pamięci podczas tej części testu, następnie zerując pamięć dzieloną, cache i bufory, jednocześnie mając wypełnony RAM i cache po brzegi. Jeśli to nie wystarcza, 2.4.10-ac12 alokuje i zwalnia 25MB kawałek pamięci, podczas gdy zbiór roboczy jest cały czas przetwarzany przez jądro. Przez cały czas jądro 2.4.10-ac12 ma tendencję do zabijania lub wysyłania sygnału 9 do niektórych aplikacji ze zbioru roboczego, ale pomimo to system spędza nad tym 300MB zbiorem około 3 godzin (inne części testu powodują, że całość trwa nieco ponad 3 godziny).

Porównując wyniki tego testu z testem na k_i386-2.4.12-0.i386.rpm przy tym samym 300MB zbiorze roboczym, okazuje się że jest tu mały narzut. Następnie, 300 + 60 wypełniło cały RAM, a potem wyczyściło pamięć dzieloną, cache i bufory, ale plik wymiany zachowywał się w bardziej oczekiwany sposób, to znaczy trafiło do niego około 120MB. Jeszcze później plik wymiany nigdy nie był całkowicie wypełniany tak, jak to było oczekiwane.

W kwestii badania, czy stacja robocza odpowiada, okazało się, że nie jest tak pięknie z jądrem k_i386-2.4.12-0.i386.rpm, a wręcz przeciwnie -- szalenie, wprost szalenie ignorowana była aktywność na stacji roboczej, albo odpowiedź pojawiała się po 5+ minutach, dotyczy to odpowiedzi na tak proste rzeczy jak załączanie qps albo zmianę katalogu przy pomocy kruiser, było też sporo problemów z dostaniem się do screensavera żeby odblokować stację roboczą.

Muszę trochę poprawić moje testy. Jedną rzeczą, którą zamierzam zrobić jest przesunięcie szczegółowej informacji systemowej, którą staram się logować w trakcie testów, na inny fizycznie nośnik niż ten, na którym umieszczony jest plik wymiany. Podejrzewam, że to może zlikwidować konflikt, który może zachodzić między potrzebami systemu, który musi jednocześnie obsługiwać partycję wymiany oraz ciągłe logowanie informacji.

Muszę też znaleźć sposób zbierania pewnych informacji metrycznych w trakcie testu. Ponieważ nie jestem developerem (zajmuję się jakością i testowaniem), to może mnie kosztować trochę wysiłku wycinanie i rzeźbienie tego co potrzebuję z qps oraz xosview, żeby zdobyć informacje metryczne, których mi brakuje dla tych testów. Podejrzewam, że nie dam rady zabrać się za to cięcie i składanie przed następnym weekendem. Spróbuję wykonać te testy na 2.4.9-ac18, może nawet na 2.2.19 żeby sprawdzić, czy dają one rzeczywiście tak różne rezultaty w porównaniu do dwóch, wcześniej dziś testowanych, jąder.

wyniki qsbencha:

Linux-2.4.10-ac9:

lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
seed = 140175100
71.370u 2.560s 3:17.94 37.3% 0+0k 0+0io 11773pf+0w
lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
seed = 140175100
71.760u 3.170s 4:02.93 30.8% 0+0k 0+0io 15487pf+0w
lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
seed = 140175100
71.090u 3.080s 4:07.94 29.9% 0+0k 0+0io 15856pf+0w
kswapd CPU time: 0:23

Linux-2.4.10-ac9 + łaty Rika:

lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
seed = 140175100
71.090u 6.260s 3:21.65 38.3% 0+0k 0+0io 12868pf+0w
lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
seed = 140175100
72.460u 6.030s 3:58.10 32.9% 0+0k 0+0io 14637pf+0w
lenstra:~/src/qsort> time ./qsbench -n 90000000 -p 1 -s 140175100
seed = 140175100
71.630u 7.400s 4:00.86 32.8% 0+0k 0+0io 14894pf+0w
kswapd CPU time: 0:21

Bob Matthews zgłosił oopsa w 2.4.11; Linus Torvalds zidentyfikował problem i spytał, czy nikt nie napisałby łaty na to. Alan Cox odpowiedział: "Ingo napisał łaty na -ac już dawno temu. Nie wysyłałem Ci ich do tej pory, ponieważ nie wydawało się to zbyt istotne w kontekście innych łat. Jeśli chcesz, mogę je wyodrębnić jutro."

W całkiem innym wątku, dotyczącym innych kwestii technicznych, pod tytułem: [patch] .version, newversion w Makefile, Rudi Sluijtman zgłosił: "Przez zmianę w głównym Makefile, plik .version jest nadpisywany pustym plikiem, przynajmniej od wersji 2.4.10-pre12, więc wersja pozostaje 1 po każdej rekompilacji." Russel King odparł, że w serii -ac była łata, która to naprawiała, a David S. Miller dodał: "Ja także, niezależnie, wysłałem Linusowi łatę na ten problem. Zupełnie niezależnie od łaty w -ac." Russell odpowiedział "Łata została wysłana około 20 września do Alana, Linusa i na lkml ;(" a Alan dodał (odpowiadając Davidowi): "Może w koñcu zauważy. Russell wysłał mu poprawki, ja mu wysłałem poprawki Russella, a teraz Ty mu wysłałeś poprawki 8)"

Wątek się zakoñczył w tym miejscu. Gdzie indziej, w wątku: Uhhuh.. 2.4.12, Linus ogłosił:

W 2.4.11 była poprawka chroniąca przed atakiem typu DoS wykorzystującym dowiązania symboliczne, ale niestety ta poprawka spowodowała, że tworzenie plików przez robienie dowiązañ symbolicznych zostało zepsute (i-węzeł, który był tworzony, był tym samym i-węzłem co w dowiązaniu symbolicznym, co miało nieciekawe implikacje).

Na szczęście nikt nie postępuje w ten sposób -- czy raczej _prawie_ nikt. Wygląda na to, że instalator SuSE (yast2) to wykorzystuje, co powoduje tworzenie wrednych, nie do wytępienia i-węzłów takich jak /dev/mouse, jeśli użyjesz yast2 na 2.4.11.

("debugfs -w rootdev" + "rm /dev/mouse" usunie to, ale podejrzewam, że są mniej drastyczne metody, których można w tym celu użyć, jeśli fsck nie wykryje żadnych problemów. Do tej pory dostałem tylko jeden raport na temat takich problemów).

Zrobiłem więc 2.4.12 i zmieniłem nazwę jądru, które miało numerek 2.4.11.

ostateczna wersja:

Greg KH: aktualizacja USB (poprawki przekroczeñ czasu oczekiwania UHCI, odłączenia szeregowe)
Christoph Rohland: poprawki blokad pamięci dzielonej
Al Viro: czyszczenie kodu montowania
ja: poprawki złego traktowania obsługi link_count
David Miller: aktualizacje dla Sparca, czyszczenie kodu sieciowego
Tim Waugh: aktualizacja kodu obsługi portu równoległego
Jeff Garzik: aktualizacje sterowników urządzeñ sieciowych

Niedługo później odpowiedział sam sobie, po znalezieniu kilku kolejnych błędów dodając: "Z drugiej strony, dobrą wiadomością jest, że w miarę szybko rozpocznę 2.5, po prostu dlatego, że Alan znacznie lepiej sobie radzi z utrzymywaniem serii stabilnych ;)"

Marco Colombo spytał: "Czy Alan będzie wydawał 2.4.13 asap z VM Rika? -- (przepraszam, nie mogłem się powstrzymać)" Alan odrzekł: "Myślę, że 2.4.13 będzie jeszcze Linusa."

Paul Gortmaker odkrył, że załatanie programu diff, tak aby wczytał wszystkie pliki do cache przed porównaniem ich, spowodowało pięciokrotne przyspieszenie diffowania drzew jądra. Gdy pliki były już w cache, jego łata powodowała lekki spadek wydajności. Linus Torvalds zasugerował wczytywanie do pamięci po jednym katalogu, tak aby zredukować zużycie pamięci. Dodał: "Już od dłuższego czasu myślałem nad dodaniem funkcji systemowej ,,readahead()''. Jest po prostu zbyt dużo potencjalnych możliwości wykorzystania, wyszło to w wielu różnych miejscach..." Zasugerował wysłanie łaty do zarządzającego diffem, mówiąc: "Ta zmiana wygląda na małą i wystarczająco prostą, aby ją zaakceptowano, a ja bardzo bym chciał ją mieć. Tak czy siak, i tak przypuszczalnie włączę ją do mojej wersji, ale byłoby przyjemniej nie musieć łatać diffa oddzielnie..."

Marcelo Tosatti przywołał materiały z USENIX 2001, dotyczące tej kwestii, zatytułowane Projekt i implementacja algorytmu przewidywalnego wychwytywania plików. Dodał: "Mają implementację tego skomplikowanego algorytmu przewidywania dla Linuksa, ale sądzę, że wczytywanie całego katalogu na zapas ma sens w większości przypadków."

Gdzie indziej, Willy Tarreay wyjawił zaklęcia na bardzo szybkie uzyskiwanie wyników diffa:

Osobiście używam twardych dowiązañ pomiędzy jądrami, w celu uzyskania mniejszego efektywnego zbioru danych i chciałbym wyjaśnić tu, jak to robię, ponieważ jest wiele osób, które są bardzo zdziwione metodą, której się nauczyłem na LKML parę lat temu:

# cd /usr/src
# tar Ixf anydir/linux-2.4.12.tar.bz2
# cp -dRflp linux linux-2.4.12

w ten sposób tylko węzły katalogów są zduplikowane, więc narzut jest mały

# (cd linux && bzcat anydir/patch-2.4.13pre1.bz2|patch -Np1)
# cp -dRflp linux linux-2.4.13pre1

teraz, tylko pliki zmodyfikowane przez łatę są zduplikowane, możesz pracować wewnątrz katalogu linux i tworzyć własne łaty bardzo szybko, ponieważ tylko kilka plików pomiędzy starym i nowym drzewem się tak naprawdę różni.

Uważajcie, aby nie zmodyfikować pliku z wieloma dowiązaniami, jeśli by się to stało, to zmieni się on we wszystkich drzewach i zmiany nie będą widziane w diffie. Edytor musi odłączyć dowiązanie przez zapisem.

Mam nadzieję, że to komuś pomoże, tak jak pomogło mi jakiś czas temu. Teraz diffy wykonują mi się w ułamku sekundy, mimo że nie mam zbyt dużo RAM-u.

Horst von Brand zauważył, że większość edytorów nie usuwa dowiązania przed zapisem. Jedynym, który znał był jed. Nick Craig-Wood zauważył: "emacs wykonuje mv plik plik~ przez zapisem pliku, więc edytowany plik nie będzie miał dowiązania, a plik zapasowy będzie miał. Możesz uniknąć tego ustawiając backup-by-copying-when-linked." Wojtek Pilorz, który używa podobnej metody co Willy, zaproponował:

Aby być pewnym, że nie zrobię żadnych zmian w oryginalnym drzewie, wykonuję
chown -R root.root oryginalne_drzewo

zanim skopiuję je (przez cp -lR) do nowego, które będzie modyfikowane przez mnie, jakimś narzędziem, gdy będę zalogowany jako zwykły użytkownik. Dla tych, którzy mają dostęp do konta roota na komputerze, to może być wygodny sposób zapobiegania wypadkom... (to oczywiście zakłada także odpowiednie uprawnienia dostępu do plików)

Patrick McFarland spytał, dlaczego Linus Torvalds użył "prostej" wersji podystemu pamięci wirtualnej Andrei Arcangeli, podczas gdy kod VM Rika van Riela w wersjach Alana Coksa jest zajebisty. Linus odpowiedział, ""złożony" != "sprytny". Benchmarki, które widziałem mówią, że prosta obsługa pamięci wirtualnej ma lepsze wyniki - zarówno w kwestii powtarzalności jak i bezwzględnej wydajności. Sam przeszukaj tę listę, jeśli mi nie wierzysz. " W innym miejscu Alan także odpowiedział Patrickowi: "Nie ma żadnej koñcowej konkluzji na temat pamięci wirtualnej - są rzeczy, które wskazują, że implementacja Rika działa dobrze, ale czasem przełącza inne rzeczy, a kilka fragmentów jest ciągle niby hakerskich. zSmart często się przydaje -- zwłaszcza, gdy chcemy sprawdzić jak wolne jest wyszukiwanie po dysku. Ale spryt nie nadaje się do wszystkich algorytmów."

Gdzie indziej Luigi Genoni zauważył: "Nie obchodzi mnie, który VM jest prostszy, ani który jest szybszy. To czego chcę, to przewidywalność, ponieważ to jest najistotniejsza rzecz na serwerach, którymi administruję. W niektórych, szczególnych sytuacjach potrzebuję czegoś może mniej przewidywalnego, ale na tyle sprytnego, aby poradziło sobie z duzym obciążeniem." Rik odpowiedział:

Teraz mamy nieco inne podejście do sytuacji. Większość czasu we wczesnych jądrach 2.4 spędziliśmy szukając błędów powodujących pady komputerów, nie zwracając uwagi na wydajność.

Dopiero w ostatnich jądrach -ac miałem tak naprawdę trochę czasu, aby popatrzeć na wydajność i zwiększenie wydajności VM wydaje się całkiem proste.

Wygląda na to, że VM Andrei jest zoptymalizowany pod względem wydajności przy małym i średnim obciążeniu... ale w Linuksie 2.2 mogliśmy zobaczyć, że w zasadzie jest niemożliwa optymalizacja tak prostego VM, aby nie padał przy bardzo dużym obciążeniu, więc ja tak nie będę robił ;)

Robert Love zauważył, że drzewo Alana jest bardziej stabilne. Patrick spytał, czemu tak myśli, a Robert odpowiedział, że kod Alana nie był tak bardzo modyfikowany, jak Linusa. Później Rik dodał:

Zauważcie, że Linus nie był na bieżąco z moim VM mniej więcej od 2.4.5. I zanim zaczniecie mnie winić o niewysyłanie łat, wiedzcie, że je wysyłałem, ale Linus nie zaaplikował ich z nieznanych mi powodów.

VM w jądrze Alana jest w zasadzie jedyną możliwością posiadania sprawnego jądra 2.4 od czasów 2.4.7.

Christoph Lameter zauważył, że 2.4.11 nie ładuje sterownika urządzenia loop, pokazując błąd typu nieznany symbol z informacją "moduły nie będące na licencji zgodnej z GPL nie mogą używać symboli GPLONLY_". Według niego nie ma to żadnego sensu, bo sterownik urządzenia loop jest dystrybuowany z jądrem i jest właściwie licencjonowany. Keith Owens wyjaśnił, "Jeśli symbol był wyeksportowany z EXPORT_SYMBOL_GPL to jest on nierozwiązywany dla modułów, które nie mają zgodnego z GPL MODULE_LICENCE. Zatem, gdy moduł nie mający zgodnego z GPL MODULE_LICENCE dostaje nierozwiązany symbol, wyświetlam informację jako wskazówkę dla użytkownika. Wydawało mi się, że odpowiedź była oczywista, ale wygląda na to, że muszę rozszerzyć treść tej wskazówki. " Christoph powtórzył, że sterownik urządzenia loop jest zgodny z GPL, a Keith odpowiedział, "W 2.4.11 loop.c nie ma MODULE_LICENCE. Zajmie trochę czasu zanim wszystkie moduły zostaną poprawnie oznaczone." Kilka wiadomości dalej, w tym samym wątku, Ben Greear zaproponował "Czy nie mógłbyś zmienić tego na ostrzeżenie i dać ludziom parę miesięcy na poprawki? Wielce podejrzanym jest dla mnie kod, który nie służy celom technologicznym, ale znacznie zmniejsza funkcjonalność jądra. Może nawet trzebaby poczekać na 2.5..."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	28 Sep 2001 - 15 Oct 2001	(16 posts)	Stan obsługi linmodemów w jądrze; nowa procedura obsługi zwrotnej plików /dev w przestrzeni użytkownika
2.	10 Oct 2001 - 11 Oct 2001	(37 posts)	Identyfikowanie jąder skonsolidowanych z niedebuggowalnym kodem
3.	10 Oct 2001 - 14 Oct 2001	(12 posts)	Porównanie dwóch podsystemów pamięci wirtualnej
4.	10 Oct 2001 - 11 Oct 2001	(20 posts)	Stan prac nad 2.4, 2.4-ac i 2.5
5.	14 Oct 2001 - 18 Oct 2001	(22 posts)	Przyspieszania diffa na drzewach jądra
6.	15 Oct 2001 - 17 Oct 2001	(34 posts)	Dalsza dyskusja nad zmianami obsługi pamięci wirtualnej w 2.4
7.	16 Oct 2001 - 18 Oct 2001	(20 posts)	Trudności w śledzeniu modułów niezgodnych z GPL

Kernel Traffic #138 For 22 Oct 2001

By Zack Brown

Translated By: Maja Królikowska and Paweł Kot